hangover


Hi. If I include a database in my compiled application via the Project Manager, how do I then reference it and its tables Do I still need to open the database and tables or are they automatically opened

Thanks.





Re: Include DB in .exe

Craig Berntson


You use it exactly the same way as if it was excluded. However, it will be read only and you will not be able to make changes to it.





Re: Include DB in .exe

Carl Warner

As Craig said, your database will be read only. It will only serve as a lookup database with lookup tables that are static. If you want to create a new database on the fly, document the design of your database with GENDBC.prg and have your program then use that code to generate a usable new database from your application.

Gendbc.prg
http://msdn.microsoft.com/library/en-us/dv_foxhelp9/html/f43d54d7-0564-452f-9fea-7f927dc729aa.asp frame=true

How to Use GENDBC to Create Utility that Recreates Complex CDX
http://support.microsoft.com/kb/135112

PRB: Application Unable to Edit Database Files
http://support.microsoft.com/kb/87696






Re: Include DB in .exe

hangover

Thankyou both. The database is a pre-existing database consisting of tables which are only used for lookup purposes so read-only is fine. However, I cannot get it to work. When I include the database and tables within the exe, and then remove or rename the directory where they are located, the application can no longer find them.

I am opening the database and tables via a function I have written which takes the database path and name as an argument. Could this be the problem - i.e. would it find the tables if they were referenced directly (i.e. USE f:\standing data\applications IN 0), rather than via a parameter (i.e USE (lcTable) IN 0)






Re: Include DB in .exe

Carl Warner

Keep in mind that each table that is part of your database container has backlink data stored in the header that tells where the dbc is. If you start moving the dbc and its table around, you destroy the integrity of that backlink information and confuse the heck out of your app in this case.



Re: Include DB in .exe

hangover

Thanks again Carl.

Perhaps I am confused about what 'including' a database entails. I assumed that once the database and tables had been included they became part of the .exe file and hence the individual files (.dbf, .dbc, etc.) were no longer required. Hence, I was deleting or renaming the directory in which these files existed after building the .exe in order to check that it worked (i.e. that it was accessing the database and tables within the .exe file and not those in the directory). However, when I run the .exe after deleting or renaming the directory it produces error messages stating that it cannot find the tables, which indicates to me that it is still looking for them in the directory rather than within the .exe file.






Re: Include DB in .exe

AndyKr

The issue is not whether you have the tables or not, but how they are being referenced in your code. By default VFP uses RELATIVE PATHS in form dataenvironments and Views to locate the source tables (unless they are on a different physical drive - in which case the fully qualified Drive and Path is used).

So unless you created your forms in the SAME directory as the tables, your forms and views will be trying to use tables like this:

USE ..\Datafiles\table_name

SELECT FROM ..\Datafiles\table_name

And obviously, if you include the tables in the EXE such path references will be invalid and the commands will fail.

The only way to do this is to ensure that all paths for tables that you are building into the EXE are explicitly removed from the form DE and any View definitions before compiling the application so that VFP will not look along a specific path but will use whatever it can find first - which will now be the embedded, read-only, tables in the EXE.

One way to do this is to move these tables into the same directory as the DBC (which will resolve the view issue) and then into the same directory as the forms (which resolves the form issue.

However, a better solution is NOT to use such tables in Views at all, and never open them implicitly in form DataEnvironments - use the USE command in the Form LOAD() event instead.






Re: Include DB in .exe

hangover

Fantastic, many thanks Andy. My application works now.

I am not using the tables in any form dataenvironments or views, I am opening them explicitly in my code (and not even in a form's LOAD() event - the database and tables are opened through a method in a custom class object before any forms are instigated) and they are in the same directory as the database (I always ensure this). However, I did not realise that once they had been 'included' I could no longer reference them by their relative path (which I can do with forms, program files, etc.) but only by referencing them without a path. Hence OPEN DATABASE "\standing data\standing_data" fails, but OPEN DATABASE standing_data is successful.

I've only just discovered this forum (I've been using FoxPro for around 15 years and use to post a little bit on the CompuServe forum and subsequently on FoxUK) and I think it is going to be invaluable!

Dom






Re: Include DB in .exe

AndyKr

Glad I could help.

You might also want to check out FOXITE (www.foxite.com) it's free and has lots of very friendly and willing people too.






Re: Include DB in .exe

hangover

Ta, I will check it out.