opinion wanted about maintaining .DBC .DBF etc.on the fly

[Nifrabar]

Hi to all of you!
At long last I got my SDT proper working in my develop APP.
Now I wonder about rolling into the .EXE tables for distribution.
I am thinking of rolling into the .EXE all tables required by SDT to do automatic updates. That's adviced to me here in the forum.
But to be sure also the right .DBC is in the APP I intend to also roll the .DBC etc. into the .EXE.
Than, when starting the APP, I will firstly copy all these files as mentioned above to their locations and than let SDT update if necessary the .DBF's and .CDX's
Will that be a good solution?
-Bart

 

[bobmpalmer]

You don't really need to build the DBC into the exe and copy out. If you use SDT to create your DBCXreg Coremeta and SDT files along with just your DBC (DBF,FPT,CDX not reqired) you can store it in a metadata folder and use SDT to create your working folder and tables. When you issue an update you just need to issue the new metadata folder with a flag file so your app can see its an update and call the SDT .update() method.

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Nifrabar]

Bob,
You are telling me that there is no need to send new .DBC to my client? In former threat I was adviced to do so!
Also next I have to take into account.
I do have a simple back-up facility in my app which zips the full data-map (incl. .DBC) into a backup-map.
The reason I liked to include my .DBC into the .EXE is that once a back-up should be restored there must again be done an update to that .DBC to remain in sync with the development.
But how can I roll all these files in the .EXE and extract them to the right location?
-Bart

 

[ramani]

Hi

Tables/DataBase upgrade to applications is handled by me in a dynamic manner. I keep one myUpgrade.PRG. All the data upgrades are coded example.. ALTER TABLE... syntax. The application itself has the version number auto incremented with every compilation. SO I check the version number, if that is not matching with the data version stored in data (make sure this data is poart of data at clients place so that any backup restored will bring back the version number related back into harddisk), the related part of myUpgrade.prg fixes that. This function will be called at the beginning of the real application with code..

IF cur_version < nnnn.1234
Do whatever.. set the ver. number in data area
ENDIF

IF cur_version < nnnn.4567
Do whatever.. set the ver. number in data area
ENDIF

so the application rolled out can easily bring any data to the current version level. This takes care of all upgrads as time progresses and no future effort is required to upgrade data.



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[ramani]

I forgot to mention about one important thing I follow. I dont store any procedure/triggers in DBC. Instead I code them all as part of my Main.Prg at the end. So all triggers go back to that.

The drawback, some may think is that, you cant get into direct mode and alter data. I conside that as positive so that no one can get into direct mode and tamper the data. For my own use, I set procedure to a PRG which contains all the trigger procedures so recorded, that when I get in direct mode for whatever reason, everything will trigger correctly.



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[Olaf Doschke]

Hi Nifrabar

Bob,
You are telling me that there is no need to send new .DBC to my client? In former threat I was adviced to do so!

Well, you shouldn't perhaps start new threads if they continue about the same problem... By the way, a threat is something comletely different ;-)

Well, rgbean has answered (

http://www.tek-tips.com/viewthread.cfm?qid=944527)

with the advice to include a selfextracting zip exe. How to extract embedded files from an exe? You may follow this link:

http://www.tek-tips.com/viewthread.cfm?qid=934670

And how to embed files? Simply add them to "other files" in your project.

Bye, Olaf.

 

[Nifrabar]

Ramani,
Your solution is OK. Up to now I used to update my DBC that way. But now that SDT is included I thought using that some more extended to overcome to 'forget' small changes in the DBC.

Olaf,

[i]Well, you shouldn't perhaps start new threads if they continue about the same problem... By the way, a threat is something comletely different[/i]

In my opinion, but correct me if I'm wrong, it happens quit often that one runs from the original topic. So more threats could help others as well once browsing the topics though? The threat I pointed to was originally about stored procedures. We went a little off-topic in that threat. So a new threat seemed better to me.

Nevertheless thanks for your help.
You pointed me to the correct way to include 'other' files.
-Bart

 

[bobmpalmer]

If you read my post I said

Coremeta and SDT files along with JUST your DBC

Meaning you dont have to include all the tables and files that are in your DBC as their structure indexes etc are stored in the SDT files just the DBC itself!



Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[bobmpalmer]

I also said to store these files in a folder we call ours "metadata", then when you wish to update your users DBC issue a new "metadata" folder with the NEW DBC and SDT files in it. Put a flag file in it i.e. upgrade.txt and look for that file in your main prg if it exists then the app sees an upgrade and runs SDT. Remember to delete the upgrade.txt file after SDT has finished!


Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Olaf Doschke]

Hi Nifrabar,

glad I could help.

Well, if you want to cut a thread and start a new one, because you feel the topic has changed, you could at least post somee message like "I've started a new thread (link), please post replies there", that'll be helpful.

It's still not threats we're talking about. Nobody will threat you to do something here ;-).

Well, if you backup your complete data (tables and dbc), if you just replace dbc,dcx and all the stonefield files they may no longer correspond to the tables structures. So just changing bdc and other files except the DBF's etc is only recommended, if you just want the stored procedures chaged, not if you want to change table structure, because you don't want to loose data, do you?

So perhaps you need an update-routine running anyway.
And after such an update all old zips of the database are outdated and restoring them will be fatal, no matter if you restore all files of the zip or update the DBC etc afterwards.

If you store some version number, perhaps in the dbc comment, you should compare this and if it's older than needed by the current apps version redo the changes with code like ramani suggests.

Additional to that, the last version of dbc etc. stored within the exe can be helpful, if you detect some corruption and no database update or restoring of an old version was done.

Bye, Olaf.

 

[Nifrabar]

Gentlemen,
Thanks for your opinions so far. As I realise there are several ways (as mostly with VFP) to solve my 'problem'.
For now I have to make a decision which solution fits best for me.
Also good to learn again some more of the 'english' language in here (Bob<g>).
And Olaf, I agree and apologise for not telling in other thread about this ´continuing story´.

-Bart