Had to go back to crack open some files from 3 years ago to see what my practice was when I was still programming. I had come to the conclusion that TAFs should never interact with the DB directly, but should be used mostly for presentation. This is where I was: * all DB actions done via methods * TCFs initialize instance variables with the DSN parameters * instance variable assignments are stored in an include file,
So similar to Dale, except the DB administrator could separately maintain these credentials, and no need to restart the witango server -- only reinstantiate objects. This approach supported robust development with the consistency checks centralized in the database access methods; TAFs can be simpler as a result. On Feb 26, 2011, at 2:55 PM, Dale Graham wrote: > While I agree with you generally, there IS a work around that does very well > -> for hiding deployment info in TAFs. Unfortunately, development connectors > (though encrypted) are still somewhat at risk. > > We define system variables (e.g. variables specified in the witango.ini > file) with names like DSName, DSHost, DSusername, DSpassword - the data for > the database connection is specified for deployment on that particular server > (so the production server's info points to production DB, development to the > development DB, etc) (Multiple datasources can be specified as different > variables, of course). At any rate, there's nothing in the TAF except a > pointer to a variable that only exists on the server. > > In the taf, for the database deployment info (set this up from the Database > properties, so it's used by every TAF), you just use > > Name <@var system$DSName> > Host <@var system$DSHost> (or leave empty) > User <@var system$DSUsername> > Password <@var system$DSpassword> > > Instant switching. Handy, too, to do quick switches in DB information (e.g., > periodic changes in DB passwords, etc). No changes whatsoever needed to the > tafs, just to the Witango.ini file(s) affected. Works a champ. > > > > ---------------------------------------- > > To unsubscribe from this list, please send an email to [email protected] > with "unsubscribe witango-talk" in the body. > <PastedGraphic-3.pdf> > > > On Feb 26, 2011, at 3:22 PM, William Conlon wrote: > >> My recollection is that changing studios (e.g. to a new machine), >> potentially with new odbc drivers, would necessitate re-creating the data >> sources. The .taf would get littered with duplicate datasource stanzas and >> the studio would get hopelessly confused. >> >> Another reason to remove data source definitions from the taf is security -- >> the database credentials are exposed to programmers. Far better to move >> them outside to a .ini file, with a preference in the studio pointing to a >> local file on a workstation and parameter in witango.ini pointing to a file >> on the server. On the programmers workstation, the .ini might contain >> limited credentials (DESCRIBE), whereas the server could include credentials >> for MODIFY, INSERT, DELETE. >> >> On Feb 24, 2011, at 8:28 AM, Robert Shubert wrote: >> >>> Bill, >>> >>> Are you suggesting that the problem that Mikal is experiencing is directly >>> related to a bug in Witango? I believe he is moving to a new server, but >>> otherwise replicating the configuration, I don't believe that Witango >>> should cause this problem unless something else has changed. >>> >>> Regarding your suggestion of the dsn.ini file, I came to a similar >>> conclusion long ago, however since then I have decided to do away with .ini >>> files altogether and am developing a method of managing data source >>> information within the application itself. >>> >>> Robert >>> >>> -----Original Message----- >>> From: William Conlon [mailto:[email protected]] >>> Sent: Thursday, February 24, 2011 12:02 AM >>> To: [email protected] >>> Subject: Re: Witango-Talk: Invalid object name >>> >>> long standing bug. can't recall exactly how this would appear, but my >>> workaround was to global search and replace the DataSource stanzas in >>> BBEdit. >>> >>> BTW Robert, this is one of several reasons I asked for <DataSource> stanzas >>> to be defined in dsn.ini, outside the .taf. >>> On Feb 22, 2011, at 3:26 PM, Robert Shubert wrote: >>> >>>> Also, I think you have to have the username explicitly mapped to the table >>>> owner - so that it assumes that owner name. Check >>>> Security>Logins>username>User Mapping and then see if it's mapped to dbo >>>> rather than TGO_DEVL on the database that you are accessing. >>>> >>>> Robert >>>> >>>> -----Original Message----- >>>> From: Mikal Anderson [mailto:[email protected]] >>>> Sent: Tuesday, February 22, 2011 5:29 PM >>>> To: [email protected] >>>> Subject: Re: Witango-Talk: Invalid object name >>>> >>>> Check - the ODBC DSN default database points to the correct dB. >>>> >>>> This statement produces an error: >>>> >>>> SELECT * >>>> FROM LocDef >>>> WHERE Loc_ID=1 >>>> >>>> This does not: >>>> >>>> SELECT * >>>> FROM TGO_DEVL.LocDef >>>> WHERE Loc_ID=1 >>>> >>>> Inclusion of TGO_DEVL, the table owner, is the only difference between >>>> the two statements. >>>> >>>> Further, the first statement runs in the Witango Studio SQL Query window >>>> without error, whereas running it from the .taf errors out (Deployment >>>> DS and Development DS same for all actions). >>>> >>>> >>>> On 2/22/2011 13:32, Robert Shubert wrote: >>>>> Right- but when you build the ODBC DSN - the screen after you enter the >>>>> username/password asks for a Default Database - this needs to point to >>>>> the correct database. >>>>> >>>>> Robert >>>>> >>>>> -----Original Message----- >>>>> From: Mikal Anderson [mailto:[email protected]] >>>>> Sent: Tuesday, February 22, 2011 2:43 PM >>>>> To: [email protected] >>>>> Subject: Re: Witango-Talk: Invalid object name >>>>> >>>>> The ODBC data source name is the same but the server name is different. >>>>> >>>>> On 2/22/2011 11:36, Robert Shubert wrote: >>>>>> In the ODBC setup, are you changing the database? >>>>>> >>>>>> Robert >>>>>> >>>>>> -----Original Message----- >>>>>> From: Mikal Anderson [mailto:[email protected]] >>>>>> Sent: Tuesday, February 22, 2011 2:02 PM >>>>>> To: [email protected] >>>>>> Subject: Witango-Talk: Invalid object name >>>>>> >>>>>> Hello List -- >>>>>> >>>>>> We're moving our Witango installation from one server to another and for >>>>>> some reason the new installation is now demanding that the table owner >>>>>> (tableOwner.tableName) be prepended to each dB action. Here's the error: >>>>>> >>>>>> An error occurred while processing your request: >>>>>> File: fctChecks.taf >>>>>> Position: get_dLocDef >>>>>> Class: DBMS >>>>>> Main Error Number: 208 >>>>>> >>>>>> [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name >>>>>> >>>>>> 'LocDef'. >>>>>> 42S02 >>>>>> >>>>>> I solved this once several years ago--it's probably ridiculously >>>>>> simple--but cannot remember the solution. The ODBC setup is the same. >>>>>> The dB permissions check. What am I missing? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>> >>>>>> To unsubscribe from this list, please send an email to >>>>>> [email protected] with "unsubscribe witango-talk" in the body. >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>> >>>>>> To unsubscribe from this list, please send an email to >>>>>> [email protected] with "unsubscribe witango-talk" in the body. >>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> Mikal Anderson >>>> www.LakeOMedia.com >>>> "What has your website done for you lately?" >>>> >>>> >>>> This message, including any attachments, is confidential and intended >>>> solely for the person(s) or organization to whom it is addressed. If an >>>> NDA has been signed by the parties, this communication is governed by the >>>> stipulations contained within that NDA. >>>> >>>> If you are not the intended recipient, or have received this message by >>>> mistake, please notify Mikal Anderson, the original sender, and delete >>>> this message from your system. Any unauthorised use, forwarding, or other >>>> dissemination of this message, in whole or in part, is strictly prohibited. >>>> >>>> >>>> >>>> >>>> ---------------------------------------- >>>> >>>> To unsubscribe from this list, please send an email to >>>> [email protected] with "unsubscribe witango-talk" in the body. >>>> >>>> >>>> >>>> ---------------------------------------- >>>> >>>> To unsubscribe from this list, please send an email to >>>> [email protected] with "unsubscribe witango-talk" in the body. >>>> >>> >>> Bill >>> >>> William M. Conlon, P.E., Ph.D. >>> Consulting Engineer >>> 2330 Bryant Street >>> Palo Alto, CA 94301 >>> vox: 650.327.2175 (direct) >>> fax: 650.329.8335 >>> mobile: 650.906.9929 >>> e-mail: mailto:[email protected] >>> web: http://www.wmconlon.com >>> YahooIM: wmconlon >>> AOL IM: wmconlon >>> >>> >>> >>> >>> >>> >>> ---------------------------------------- >>> >>> To unsubscribe from this list, please send an email to [email protected] >>> with "unsubscribe witango-talk" in the body. >>> >>> >>> >>> ---------------------------------------- >>> >>> To unsubscribe from this list, please send an email to [email protected] >>> with "unsubscribe witango-talk" in the body. >>> >> >> >> >> >> ---------------------------------------- >> >> To unsubscribe from this list, please send an email to [email protected] >> with "unsubscribe witango-talk" in the body. >> > > > > ---------------------------------------- > > To unsubscribe from this list, please send an email to [email protected] > with "unsubscribe witango-talk" in the body. ---------------------------------------- To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body.
