Data vs. Structure

[John Gamble]

Conundrum ?

At night, after the day job I would like to transfer ONLY the non data files to a cd and take home. The theory being, to make structural changes and/or add new features & test on dummy data. The following morning, transfer the adds/changes to work & update the live data. I realize that structural changes normally update the data files immediately. Does any one know of a way to accomplish this, and if so what data files wouldn't be copied.

Thanks in advance
John Gamble

[forskare]

RE: Data vs. Structure

John,

This has been asked several times. Try a search on .adb or .alm and see what you find. It might be easier toi make a copy at work, empty the data and xfer the copy and the return the favor to work. Then append the data to the updated version. It'll save check, recheck and triple chek to make sure you've left nothing out.

Others may have a better solution.

kenn

[Edward F. Schulz]

RE: Data vs. Structure

John,

Ken is on the right track but I'd like to add more detail. I assume
that all of your database is in 1 folder, if not it should be. Make a
new folder and copy the entire database into the new folder. Then go
into the temp folder and open the control panel. Highlight each table
and then empty the contents. Now zip up the temp folder (it may very
well fit on a floppy after zipping), if so you are in business. If not
you will need a burner or a zip drive. Then delete everything in the
temp folder. When you bring the database back the next day, unzip it
to a temp folder, then run an update from the real data into the temp
folder. If everything is ok, delete the contents of the original
folder and copy the temp folder into the original folder. Just be sure
that you check the new work entoto before deleting the original folder.

efs

[John Gamble]

RE: Data vs. Structure

Evening Ken
Thanks for the response. Was hoping there might be a simpler way, right! Quite a few tables & sets to append.
Thanks
John

[John Gamble]

RE: Data vs. Structure

Edward
Thanks for the reply. See my reply to Ken
John

[Tom Cone Jr]

RE: Data vs. Structure

John,

If you don't make changes in the structure of the tables with your mods you can simply copy over the old dictionary files with the new ones. Here's the sequence I follow:

1. zip entire database for transport home

2. do the mods at home

3. zip the entire revised database for transport back to the office, but 'exclude' dbf and fpt files from the new zip file. This means I am including everything except the actual data in the zip I take back to the office.

4. on arrival at the office, THE FIRST THING is to make an archival backup of the existing database. I do this every time, just before I copy the new mods in place. I do this by creating a zip file copy and storing it in an archive folder. I test the integrity of the archive copy, before proceeding.

5. I then unzip the new work file to the database folder, overwriting all the old files. Since no data files are included in my zip the actual data remains intact.

6. I then reindex all the tables.

This sequence has served me well. As mentioned at the top, it is designed for situations where no changes in the structure of any of the tables is being made. It's actually pretty easy to do. Easier to do it than to describe it. All I'm really doing is copying the database for transport home, and then copying back my changes, with provision for archive backups in case there's a glitch in the file transfer process.

Note: If your work environment is on a local area network and your database is shared with others on the LAN you will need to have exclusive access to the database files in order to do the update. If someone else on the net is working with the database some of the files you are trying to copy back to the server may be 'in use', so Windows will prevent them from being copied over. This is another reason I like making the archive backup zip file just before I do the update. If my zip utility can't get exclusive access to the files it won't include them in the zip and reports the problem. This tips me off that someone has left their machine running with the database in use.

-- tom

[John Gamble]

RE: Data vs. Structure

Tom
Appreciate the response. This would certainly work well for adding or changing forms reports etc. Unfortunately my changes often envolve structure changes. Oh well !
Thanks
John

[Terry Morgan]

RE: Data vs. Structure

Have you thought about using a dial up connection to your office to transfer files - I have been using pcanywhere for years - which makes life a lot easier than copying files on disk.
Terry

[forskare]

RE: Data vs. Structure

I make a zip copy and email it back and forth.

kenn

[John Gamble]

RE: Data vs. Structure

Terry
Have also used pcanywhere for years but it impacts on my incremental backup. Was trying to find a way around this. Thanks
John

[forskare]

RE: Data vs. Structure

John,

I make a backup, empty the data, change the field rule temporarily to user entered, zip it up and then email it.

When I'm done making changes, I email it back, append the data and then change the field rule back to auto increment.

This has worked very well for me. If you have a script for auto increment, then you'll have to disable and enable it.

If you search the this message board for auto increment, try it one word or 2 words, you'll find reference to auto increment scripts that do not need to be disabled or enabled.

Also, check out learn alpha.com. There is a recent article there by finian lennon and a down load utility that you might find interesting as well.

kenn

[russ Boehle]

RE: Data vs. Structure

This may be more work than you want to do but you could:
backup all files for cd or whatever
When you want to put it back at the office make a copy of each data file with memos.
Restore off the cd to the original location.
append the data from the copied files back into the new changed database.

You could probably automate this whole thing with a script to do it automatically.

Russ

[John Gamble]

RE: Data vs. Structure

Ken
I was refering to my daily incremental backup (by change date) rather than an autoincrement rule. Appreciate the feedback
John