>>>The problem with just adding records is that the structure of the database
>is different, so it must be changed, which makes it easier just to change the
>structure of the new file.
>
>Occassionally I need to add up to date dbf files to my project.
>>>These files will replace existing files, they just have up to date records.
>>>
>>>Is there any problem in writing over existing dbf's for a compiled program? Would any conflicts arise because these files are not physically added to each form, etc.?
>>>
>>>Thanks and have a good day.
>>
>>A couple of questions.
>>
>>1.) Why are you 'replacing' files? Wouldn't it be easier to either zap and append or update the records according to a primary key?
>>2.) Are the dbf's excluded from the executable? If they aren't, they should be.
>>
>>Out and Out replacing files can be a problem, but updating the information within a file should never be a problem.
>>
>>HTH

Sounds like you have a conceptual and a planning/development problem

1) Included tables are read-only and are static, usually setup files. Excluded files are *IN* the project but are marked as excluded (the little 'not' symbol). Excluded files are your data files.

2) You should not be continually changing the structure of your data tables and rewiting/recompiling your application. This is bad development. You should thoroughly analyze the needs of you application and develop a comprehensive data dictionary. You should then test with the source code (not compiled) and make changes prior to compiling.

If, after testing, and having begun initial rollout, you discover that you need to add/change data structures: modify the development data, test it and then either manually or progrmatically (better option) update your table and DBC structure of the production data. From there you should zap/append or update whatever tables necessary from the development data.

This may sound like a cumbersome process, but it's really the only way I know to do it safely.