Using the data environment to open a table with the current DBC at run-time.

[AndrewMozley]

I have an application in which there are several forms, each of which uses its data environment to specify the tables which should be opened for that form.

The properties of each table (Mytable1) include a ‘Database’ property. This is taken from the database from which I selected the table at the time the form was designed. So this might be “Myfolder\Mydatabase.dbc”

When the application runs, the table which needs to be opened is a table (MyTable1), but within a database specific to the client; this database will already be open; it might be users\GeneralCo\Data\ClientData.dbc.

In general this works fine; but if, on the client’s machine, there is a database Myfolder\Mydatabase.dbc, it is from that database that the table will be opened; I do not want that.

My understanding is that the database property is read only. I saw some discussion (back in 2005) about how the database property could be altered, but was unable to work through it.

If anyone can provide simple guidance on this matter I would be grateful.

Andrew

 

[Olaf Doschke]

The way it still works mostly is because VFP searches for DBFs in SET("PATH") and so that database attribute of DE objects is indeed quite unimportant, but can bite you, if there really is such a db.

It's one of the reasons I don't like the DE and rather prefer some USE dbcname!tablename or even just relying on the current DBC and USE tablename only.

One way to cope with it in general is with code in the DE.BeforeOpenTables() method, eg look into

http://www.jamesbooth.com/remotedata.htm

Bye, Olaf.

 

[mjcmkrsr]

Hi,
Please do also have a look at
[link ]

http://support.microsoft.com/kb/128996/en-us

[/url]
hth
MK

 

[Olaf Doschke]

Indeed KB128996 offers and describes the solution quite well. The paragraph about SET PATH should be rounded up by saying VFP obviously can only find a database with same stem name (stem as in JUSTSTEM(), the mere name of a file without it's path and extension), it doesn't take any DBC name as replacement for the not found DBC.

In the end I dislike solutions that incorporate the discovery of the right files in some PATHs, as that is not under your full control and can be misused intentionally or more dangerous unintentionally, when databases are put in certain paths. I'm an evangelist of absolute paths derived from configured or otherwise easily determined base paths to adapt to different situations for good reasons, You may like the possibility to change an EXE behaviour from outside by reconfiguring a DSN or changing the config.fpw or putting files in certain directories, but I like to concentrate all these influences into one single config with eg connectionstrings instead of DSNs, base paths and more, maybe even for a whole suite of applications. That centralisation is really saving administrative costs and simplifies adjusting applications to many environments.

The solution to iterate the cursor objects and adapt their values at runtime is a quirk workaround for me. If a database is open having the needed tables - and the majority of VFP applications uses one such main database - then I am an absolute fan of the DBCs capability to know where its tables are by the long table names not even necessarily being the dbf stem names and being put into several subfolders giving the data a certain meaningful hierarchy in the directory level. I hear people saying that makes DBC related DBFs slow, but what's really happening? The DBC is a free DBF you SEEK in and if you're a fan of free DBFs performance it's quite self contraditory if you dislike this additional single SEEK for the DBF file name with it's long name.

So since a DBC knows it's bunch of "children" - its tables - why not make it the mother and let DE cursor objects just act on the dbf stem name by default, the database property could be made optional and when used may also just use a dbc stem name, so you could do with these objects as with the USE command, either relying on current db and USE longtablename or USE dbstemname!longtablename. And openiing a database typically is not the job of any single form, it's on the application level.

The DE class offers a general specification of the DBC used when you set DataSourceType=NATIVE, but guess where the DBC file name is put? Into the DataSource property? No, the DE builder stores it in the DE class TAG property and then into the code it generates in BeforeOpenTables. This is all very unprofessionally designed.

If you're a fan of the visual designing of table relations and the ERM you can create in the DE, there are much better diagramming tools (eg Enterprise Architect or the very simple yEd) and it is a seperate aspect for me. Your DE layout also is stored in your sepcific foxuser.dbf and if you move your source code to a customer or let a collegue work on it, the layout is lost again, if you don't share this resource dbf. So overall many features of the DE are faulty and not working good for teams.

Bye, Olaf.

 

[AndrewMozley]

Thank you for this advice, which I shall follow in the matter of removing (at run-time) the database name from the database property in the DE.

I had originally planned just to clear the no-longer-relevant value from that property at run time, but since the application knows where its data files are, I see that it makes sense to update that property so that it points to the correct folder.

Andrew