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.
