Database Updates

[TSSTechie]

Howdy

I have made a database and I will be handing it over to the end user in the next few days. Once I have done that, it would be very difficult for me to gain access to the database. What would be the best course of action should the need arise to alter the database ? Is there something I could include before handing it over that would help me in this respect (export data to csv, for example) ? Would it be possible to include a feature in any update versions that would import data from the old version whilst requiring the user to simply press a button ?
The main concern I have is that they may request that extra information be stored in the database which would require the addition of fields into the tables. How am I best tackling this ?

Ideally i'd like to be able to simply issue updates that they can setup and import data with ease rather than them getting the data to me and then me giving them back an updated database with all of their data in.

I would appreciate any advise that anyone could give me regarding how I should go about this.

Thanks in anticipation

TSSTechie

May The Force Be With You

 

[sfreeman]

Just split the db into a front-end and back-end per standard Access design, and you will not need to import anything.


Sam_F
"90% of the problem is asking the right question.

 

[TSSTechie]

Howdy,

Thanks for the super quick reply

I will look into doing that

How would I go about altering tables though ??

Thanks again

TSSTechie

May The Force Be With You

 

[sfreeman]

Not sure why you would need to do that once the db is developed. Usually data requirements will not change significantly.

There is no easy solution if they start changing the design spec on you AFTER you deliver.

I have learned the hard way to get the client to sign off on a written spec, then develop and test to their satisfaction, intall and get them to sign-off. Done deal.

If their data requirments change, it would require a new spec and development, because you simply cannot anticipate every possible change they may want.

If it is a significant change, you may actually have to start over from scratch rather than try to 'shoe-horn' new tables/fields into an existing db.

If it were my project, I would make every effort to make sure that they knew what they wanted and that my design met their spec.

To answer you question, what I have done in the past is to simply generate a series of export queries in VBA that will export all of the data in all tables to a convenient format. Also generate a series of import queries, to get the data back into the existing tables. Create saved import/export specs to make it easy on yourself and the client.

Again, the problem will be that while you will be able to backup all of the existing data, there is no guarantee that it will import back without problem into a new table structure.

HTH

Sam_F
"90% of the problem is asking the right question.

 

[markphsd]

I perform a lot of updates to my application.

There are often times you will want to modify the table structure, no matter how well thought out or how well you designed it from the get go.

Like you already said, they might want more information stored. Or you might decide that you want to store phone numbers in text fields, or you want to index some fields and not others.

I made the decision to go with a different method then the import export plan. I didn't like the import export plan, but properly written it would work well it seems.

I'll tell you what I have done:
Start creating update routines. Just gather bits and pieces from this site. You'll find lots of methods that get the same results, just use the most simple ones.

This is for table structures only.
I have a separate application that users can download. It holds a table of all the updates. At this point it's up to you how to store the updates, but I would just include a boolean field stating whether or not the update has been performed. And in code you can also write your error hanleing to ignore upgrades that have already happened. Such as adding a field twice.

Mark P.

Bleh