|
Since I never noticed this I will give it one more try
-----Original
Message-----
This has been a TOPIC I learned a lot from! My original problem is like this in the file ODBC.INI I have 3 lines:
[Accounting] Driver32=C:\WINDOWS\System32\RB65_32.DLL DBQ=t:\db65\kontema\faktura\0256\gl
On the fly I would like to replace the numbers 0256 with the client number from a previous choose command:
choose pkli from #values + for (ljs( namn,50 ) & klinr ), klinr from klient order by namn + where databas exi and databas <> 'OLD' formatted
*(please forgive the swenglish but I guess it can be understood)
As I do it now I load the odbc.ini into a table in the database manipulate the variable part and write a new ODBC.INI it works but I am unhappy tampering with Microsoft files. If I am the ONLY one whishing for feature in SCONNECT that allows to either go by DNS name or fully qualify driver and datasource I will not submit a featurerequest. But if someone encourages me I will submit a feature request. Thanks for all the info that made understand this better. Gunnar Ekblad
-----Original Message-----
Bernie et. al.,
When you SCONNECT a database you are establishing an external data source. Now you SATTACH a table, and that SATTACHed table becomes part of the R:Base structure definition. R:Base knows about the table, its structure and where it resides. You can then SDISCONNECT the database if you do not intend to access the data for now. But when you need to access the data you need to SCONNECT again so that R:Base can validate that the data source exists, that it is available to the current R:Base session and that the current user has proper rights to the data.
The external database can be reloaded without affecting the structure in your main database. But I have personally found it advisable to SDETACH all SATTACHed tables in the main database before attempting to reload it. If I do "unload all" and then run that file I will see errors on the SATTACHed tables if I have not removed them from the structure first.
The only hitch in all of this is that if you change the structure of an SATTACHed table in the external database you must SDETACH/SATTACH the table to see the changes.
Emmitt
>Buddy, >Does it affect the sconnected database if you do a reload on the sconnected >database (while it is sdisconnected) with the table still sattach'd. (in my >app both databases are rbase). > >Bernie Lis > >----- Original Message ----- >From: "Walker, Buddy" <[EMAIL PROTECTED]> >To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> >Sent: Sunday, January 12, 2003 5:50 PM >Subject: [RBASE-L] - RE: SCONNECT & SATTACH > > > > Bernie > > I do this all the time. I SCONNECT right after I CONNECT to the > > database therefor I don't have to do sattach. I don't sdetach a table > > unless it is rarely used. Data is always up to date.. > > > > Buddy > > > > -----Original Message----- > > From: Bernard Lis [mailto:[EMAIL PROTECTED]] > > Sent: Sun 1/12/2003 4:27 PM > > To: [EMAIL PROTECTED] > > Cc: > > Subject: [RBASE-L] - RE: SCONNECT & SATTACH > > > > > > > > Razzak, > > Please clarify -- > > If you sdisconnect, the attached file appears to be still in the > > current > > database but not available for use? > > if you later sconnect without sattaching, do you have the up-to-date > > table > > or just as of originally attaching? > > > > I choose to sdisconnect and disattach when exiting the current database. > > Is > > this necessary? > > > > Bernie Lis > > > > ----- Original Message ----- > > From: "tellef" <[EMAIL PROTECTED]> > > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> > > Sent: Sunday, January 12, 2003 12:40 PM > > Subject: [RBASE-L] - RE: SCONNECT & SATTACH > > > > > > > > >In order to avoid that dialog box, you'll need to ONLY use > > >SCONNect DSNName IDENTIFIED BY UserID Password > > >command right after you connect the database, every time.< > > > > Razzak, you're right! How about that! I just tried it, > > and if you ONLY do the SCONNECT without the SATTACH, then > > those attached tables stay there and when you need to use > > them it doesn't ask for connection data. I was under the > > impression that you always had to attach them. To me it > > didn't seem to make sense that disconnecting the database > > also disconnects the SCONNECT'd database bit still keeps > > the attached tables around. > > > > > > Karen > >
Emmitt Dove Manager, DairyPak Business Systems Blue Ridge Paper Products, Inc. 40 Lindeman Drive Trumbull, CT 06611 (203) 673-2231 [EMAIL PROTECTED] [EMAIL PROTECTED]
|
- [RBASE-L] - RE: SCONNECT & SATTACH Walker, Buddy
- [RBASE-L] - RE: SCONNECT & SATTACH Gunnar Ekblad
- [RBASE-L] - RE: SCONNECT & SATTACH tellef
- [RBASE-L] - RE: SCONNECT & SATTACH A. Razzak Memon
- [RBASE-L] - RE: SCONNECT & SATTACH tellef
- [RBASE-L] - RE: SCONNECT & SATTACH Bernard Lis
- [RBASE-L] - RE: SCONNECT & SATTACH Walker, Buddy
- [RBASE-L] - RE: SCONNECT & SATTACH Bernard Lis
- [RBASE-L] - RE: SCONNECT & SATTACH Emmitt Dove
- [RBASE-L] - RE: SCONNECT & SATTACH Bernard Lis
- Gunnar Ekblad

