>>>>Is there a sort of workaround this? As opposed to bringing over the client's data to our server then append the procedures then send back the data to the client.
>>>
>>>Ramil,
>>>
>>>I keep the database version in the Comment property. Every change to the db re tables, views has its own function. If there's a catchup to do, a bunch of alter table, ... is executed with dbc opened exclusively.
>>>In the end I just overwrite database.dbf, fpt and dcx with an internal copy I made during the build process. This takes care of everything including RI. (Previously, I used to open the db as a table an replace things.)
>>
>>Do you have backlink problems with DBC overwrite? If I understand you correctly, you have two DBCs which I'll call Meta & Prod (Live). You run a function that synchs the Prod based on the Meta, then overwrite the Prod DBC/DCX/DCT with the respective Meta files?
>
>Backlink problems: None. Every table resides in the same folder as the dbc. Backlinks use a relative reference I believe.
>
>
>I would not call it Meta data. It's just a bunch of functions that say: ah this db should be at level 00020 (from the exe) and the one I am opening is still at say 00018. Then functions db_upgrade_00019() and db_upgrade_00020() are executed. Those function have been written by myself (alter table, drop table, index on, dbsetprop(), ...)
>
>Finally, after the upgrade to 00020 is done, I overwrite the dbf, dbc and dcx with data I hold in an internal table (just 3 compressed binary memo's) using strtofile().
>
>Nothing magic

Thank you for the inputs. I'll use the DBC hacking option and so far it worked great.