Upgrading to new database(HOW!)

  • Thread starter Thread starter Robert
  • Start date Start date
R

Robert

. Reply (E-mail) Forward (E-mail)

Subject: Do I have upgrading choices?
From: "Robert" <[email protected]>
Sent: 3/24/2004 4:35:42 PM




Hello stranger, I appreciate your support!

I have an Access database that I have been perfecting for
5 years now. It does all kinds of administrative tasks
that renders my company administration a breeze. My
database consists of a back end (my tables) and a front
end (my forms). The tables in the back end are linked to
the front end.

However up to now I have been doing modifications on the
actuall database, example adding fields to tables and
fields to forms, modifying fields of their data types in
tables, adding buttons in forms with new code and so
forth.... you know what I mean...

The problem with this is that I am always trying to do
this nights or weekends when no one is using the data
base and when I am finished I recompile everything so
that the next day all the users see the upgraded changes
in the database.

My question is:
Can I copy my database to another machine and do all the
neccessary modifications such as:

1- Adding, deleting or modifying fields and their
properties in tables.
2- Adding , deleting or modifying forms and their
properties.
3- Add VBA code at will.
4- Basically anything I would want to do.

and then sort of quickly upgrade the version that
everyone is using to the new version that I have been
modifying. So basically some sort of a wizard that would
actually have to copy all the data in all tables from the
old database (which includes any new appended data that
my users would have entered while I was working on the
new database) onto the new one but keeping in mind stuff
such as deleting table fields which wouldn't exist in the
new database and so forth.

Basically some sort of way to re-package my new database
with the data of the old database. Ofcourse my new
database's version would be incremented as to show that
this is the new database. But the whole idea is to do my
new database's modifications in peace over days or even
weeks without having to always meet the stressfull
deadline which says [Quote: (I have to make sure that
everything works for tommorrow or I am dead
meat!) :unquote]

I know there is a product called ODE tools, is this the
only way to do what I have explained.

Thanking you in advance for any suggestions, tips or
reccomendations.

Robert
..
 
Hi Robert

This is just a quick comment on how I handle one particular aspect of the
problem you describe. Other people will doubtless offer further suggestions.

When I design and modify an application initially, I do all of the table &
relationship changes via the Access user interface. But as soon as I have
released the first production version, I do not do any further changes like
that. Instead, I write code to make the further changes. To facilitate that,
I have various standard procedures, eg. AddTable(...) which will create a
new table in the back-end database, add a specified description to that
table, and create a link to it from the front-end. Similarly I have
AddField(), DeleteField(), AddRelation() and so on.

I put all of the changes to the current version of the database (say version
01.01), in a seperate procedure (say Upgrade_0101). Then, the startup code
checks a database property (or whatever) to see whether this is a new
front-end version being run against an old back-end database structure. If
it is, the startup code can run the appropriate Upgrade_ procedure >or
procedures< to upgrade the old back end structure, to the new one. This can
involve adding, editing, reformatting or deleting >data<, as well as
changing table structures & relationships.

By this means, you can distribute a new front-end version to any user (with
any back-end version), & the new front-end will automatically upgrade that
user's back end database to the required new structure.

HTH,
TC


Robert said:
. Reply (E-mail) Forward (E-mail)

Subject: Do I have upgrading choices?
From: "Robert" <[email protected]>
Sent: 3/24/2004 4:35:42 PM




Hello stranger, I appreciate your support!

I have an Access database that I have been perfecting for
5 years now. It does all kinds of administrative tasks
that renders my company administration a breeze. My
database consists of a back end (my tables) and a front
end (my forms). The tables in the back end are linked to
the front end.

However up to now I have been doing modifications on the
actuall database, example adding fields to tables and
fields to forms, modifying fields of their data types in
tables, adding buttons in forms with new code and so
forth.... you know what I mean...

The problem with this is that I am always trying to do
this nights or weekends when no one is using the data
base and when I am finished I recompile everything so
that the next day all the users see the upgraded changes
in the database.

My question is:
Can I copy my database to another machine and do all the
neccessary modifications such as:

1- Adding, deleting or modifying fields and their
properties in tables.
2- Adding , deleting or modifying forms and their
properties.
3- Add VBA code at will.
4- Basically anything I would want to do.

and then sort of quickly upgrade the version that
everyone is using to the new version that I have been
modifying. So basically some sort of a wizard that would
actually have to copy all the data in all tables from the
old database (which includes any new appended data that
my users would have entered while I was working on the
new database) onto the new one but keeping in mind stuff
such as deleting table fields which wouldn't exist in the
new database and so forth.

Basically some sort of way to re-package my new database
with the data of the old database. Ofcourse my new
database's version would be incremented as to show that
this is the new database. But the whole idea is to do my
new database's modifications in peace over days or even
weeks without having to always meet the stressfull
deadline which says [Quote: (I have to make sure that
everything works for tommorrow or I am dead
meat!) :unquote]

I know there is a product called ODE tools, is this the
only way to do what I have explained.

Thanking you in advance for any suggestions, tips or
reccomendations.

Robert
.
Click to expand...
 
I should add that this is where you have multiple >independent< users, each
with their own copy of the front & back end databases. But maybe some of the
same ideas would work for you.

TC


TC said:
Hi Robert

This is just a quick comment on how I handle one particular aspect of the
problem you describe. Other people will doubtless offer further suggestions.

When I design and modify an application initially, I do all of the table &
relationship changes via the Access user interface. But as soon as I have
released the first production version, I do not do any further changes like
that. Instead, I write code to make the further changes. To facilitate that,
I have various standard procedures, eg. AddTable(...) which will create a
new table in the back-end database, add a specified description to that
table, and create a link to it from the front-end. Similarly I have
AddField(), DeleteField(), AddRelation() and so on.

I put all of the changes to the current version of the database (say version
01.01), in a seperate procedure (say Upgrade_0101). Then, the startup code
checks a database property (or whatever) to see whether this is a new
front-end version being run against an old back-end database structure. If
it is, the startup code can run the appropriate Upgrade_ procedure >or
procedures< to upgrade the old back end structure, to the new one. This can
involve adding, editing, reformatting or deleting >data<, as well as
changing table structures & relationships.

By this means, you can distribute a new front-end version to any user (with
any back-end version), & the new front-end will automatically upgrade that
user's back end database to the required new structure.

HTH,
TC


Robert said:
. Reply (E-mail) Forward (E-mail)

Subject: Do I have upgrading choices?
From: "Robert" <[email protected]>
Sent: 3/24/2004 4:35:42 PM




Hello stranger, I appreciate your support!

I have an Access database that I have been perfecting for
5 years now. It does all kinds of administrative tasks
that renders my company administration a breeze. My
database consists of a back end (my tables) and a front
end (my forms). The tables in the back end are linked to
the front end.

However up to now I have been doing modifications on the
actuall database, example adding fields to tables and
fields to forms, modifying fields of their data types in
tables, adding buttons in forms with new code and so
forth.... you know what I mean...

The problem with this is that I am always trying to do
this nights or weekends when no one is using the data
base and when I am finished I recompile everything so
that the next day all the users see the upgraded changes
in the database.

My question is:
Can I copy my database to another machine and do all the
neccessary modifications such as:

1- Adding, deleting or modifying fields and their
properties in tables.
2- Adding , deleting or modifying forms and their
properties.
3- Add VBA code at will.
4- Basically anything I would want to do.

and then sort of quickly upgrade the version that
everyone is using to the new version that I have been
modifying. So basically some sort of a wizard that would
actually have to copy all the data in all tables from the
old database (which includes any new appended data that
my users would have entered while I was working on the
new database) onto the new one but keeping in mind stuff
such as deleting table fields which wouldn't exist in the
new database and so forth.

Basically some sort of way to re-package my new database
with the data of the old database. Ofcourse my new
database's version would be incremented as to show that
this is the new database. But the whole idea is to do my
new database's modifications in peace over days or even
weeks without having to always meet the stressfull
deadline which says [Quote: (I have to make sure that
everything works for tommorrow or I am dead
meat!) :unquote]

I know there is a product called ODE tools, is this the
only way to do what I have explained.

Thanking you in advance for any suggestions, tips or
reccomendations.

Robert
.
Click to expand...
Click to expand...
 
I see your point, it seems to me that you have basically
automated your upgrading tasks by creating special code
that recognizes weather it should modify or what it
should modify in the old tables when you introduce a new
version of the front end.

You see my back end is on one machine(server) and all my
other front ends are on other machines but linked to the
back end tables on the server. So, I would only have to
run the set up code once on the server to update all my
changes to my tables and copy(install) the front end to
all my other machines.

Thats cool and dandy! but before I take your idea under
my wing and begin to structure such an implementation, I
would like to know if the ODE tools would do all this for
you. The ODE tools is designed to redistribute a software
I guess.(You know with all the bleu windows set up
screens you usually see when you install or setup
upgrades from other programs).

I am a little confused with all this. But one this is for
sure, that my objective is to implement upgrading
scenarios by just giving out a new CD with the new
version where the user can install it.

I appreciate very much your time for helping me see
another point of view and I will strongly consider your
method, if there is anything else you can tell me or
guide me on this based on this letter, please do.

Thanks alot buddy!
Robert
-----Original Message-----
I should add that this is where you have multiple
independent< users, each
with their own copy of the front & back end databases. But maybe some of the
same ideas would work for you.

TC


TC said:
Hi Robert

This is just a quick comment on how I handle one particular aspect of the
problem you describe. Other people will doubtless
Click to expand...
offer further
suggestions.
When I design and modify an application initially, I do all of the table &
relationship changes via the Access user interface. But as soon as I have
released the first production version, I do not do any
Click to expand...
further changes
like
that. Instead, I write code to make the further
Click to expand...
changes. To facilitate
that,
I have various standard procedures, eg. AddTable(...) which will create a
new table in the back-end database, add a specified description to that
table, and create a link to it from the front-end. Similarly I have
AddField(), DeleteField(), AddRelation() and so on.

I put all of the changes to the current version of the
Click to expand...
database (say
version
01.01), in a seperate procedure (say Upgrade_0101). Then, the startup code
checks a database property (or whatever) to see whether this is a new
front-end version being run against an old back-end database structure. If
it is, the startup code can run the appropriate Upgrade_ procedure >or
procedures< to upgrade the old back end structure, to
Click to expand...
the new one. This
can
involve adding, editing, reformatting or deleting data<, as well as
changing table structures & relationships.

By this means, you can distribute a new front-end
Click to expand...
version to any user
(with
any back-end version), & the new front-end will automatically upgrade that
user's back end database to the required new structure.

HTH,
TC


. Reply (E-mail) Forward (E-mail)

Subject: Do I have upgrading choices?
From: "Robert"
Click to expand...
Sent: 3/24/2004 4:35:42 PM




Hello stranger, I appreciate your support!

I have an Access database that I have been perfecting for
5 years now. It does all kinds of administrative tasks
that renders my company administration a breeze. My
database consists of a back end (my tables) and a front
end (my forms). The tables in the back end are linked to
the front end.

However up to now I have been doing modifications on the
actuall database, example adding fields to tables and
fields to forms, modifying fields of their data types in
tables, adding buttons in forms with new code and so
forth.... you know what I mean...

The problem with this is that I am always trying to do
this nights or weekends when no one is using the data
base and when I am finished I recompile everything so
that the next day all the users see the upgraded changes
in the database.

My question is:
Can I copy my database to another machine and do all the
neccessary modifications such as:

1- Adding, deleting or modifying fields and their
properties in tables.
2- Adding , deleting or modifying forms and their
properties.
3- Add VBA code at will.
4- Basically anything I would want to do.

and then sort of quickly upgrade the version that
everyone is using to the new version that I have been
modifying. So basically some sort of a wizard that would
actually have to copy all the data in all tables from the
old database (which includes any new appended data that
my users would have entered while I was working on the
new database) onto the new one but keeping in mind stuff
such as deleting table fields which wouldn't exist in the
new database and so forth.

Basically some sort of way to re-package my new database
with the data of the old database. Ofcourse my new
database's version would be incremented as to show that
this is the new database. But the whole idea is to do my
new database's modifications in peace over days or even
weeks without having to always meet the stressfull
deadline which says [Quote: (I have to make sure that
everything works for tommorrow or I am dead
meat!) :unquote]

I know there is a product called ODE tools, is this the
only way to do what I have explained.

Thanking you in advance for any suggestions, tips or
reccomendations.

Robert
.
Click to expand...
Click to expand...


.
Click to expand...
 
Robert said:
I see your point, it seems to me that you have basically
automated your upgrading tasks by creating special code
that recognizes weather it should modify or what it
should modify in the old tables when you introduce a new
version of the front end.
Correct.

You see my back end is on one machine(server) and all my
other front ends are on other machines but linked to the
back end tables on the server. So, I would only have to
run the set up code once on the server to update all my
changes to my tables and copy(install) the front end to
all my other machines.
Click to expand...

Yes, understood. I sounded off about my method, then realized that your
situation is a little different (only having one BE).

Thats cool and dandy! but before I take your idea under
my wing and begin to structure such an implementation, I
would like to know if the ODE tools would do all this for
you. The ODE tools is designed to redistribute a software
I guess.(You know with all the bleu windows set up
screens you usually see when you install or setup
upgrades from other programs).
Click to expand...

Sorry, don't know. I use a different installation program. But the
installation program would just install the new FE (presumeably). The FE
would then update the database structure. Or, as you say, you could omit
that code from the FE, & run it yourself, against the BE.

I am a little confused with all this. But one this is for
sure, that my objective is to implement upgrading
scenarios by just giving out a new CD with the new
version where the user can install it.
Click to expand...

Then you'll need to consider what happens if some users run that CD, but
some don't. It seems inevitable that someone will have problems, in that
scenario. You'll end up with new FEs on an old BE, or old FEs on a new BE,
no?

I appreciate very much your time for helping me see
another point of view and I will strongly consider your
method, if there is anything else you can tell me or
guide me on this based on this letter, please do.
Click to expand...

No probs :-) Good luck.
TC

Thanks alot buddy!
Robert
-----Original Message-----
I should add that this is where you have multiple
independent< users, each
with their own copy of the front & back end databases. But maybe some of the
same ideas would work for you.

TC


TC said:
Hi Robert

This is just a quick comment on how I handle one particular aspect of the
problem you describe. Other people will doubtless
Click to expand...
offer further
suggestions.
When I design and modify an application initially, I do all of the table &
relationship changes via the Access user interface. But as soon as I have
released the first production version, I do not do any
Click to expand...
further changes
like
that. Instead, I write code to make the further
Click to expand...
changes. To facilitate
that,
I have various standard procedures, eg. AddTable(...) which will create a
new table in the back-end database, add a specified description to that
table, and create a link to it from the front-end. Similarly I have
AddField(), DeleteField(), AddRelation() and so on.

I put all of the changes to the current version of the
Click to expand...
database (say
version
01.01), in a seperate procedure (say Upgrade_0101). Then, the startup code
checks a database property (or whatever) to see whether this is a new
front-end version being run against an old back-end database structure. If
it is, the startup code can run the appropriate Upgrade_ procedure >or
procedures< to upgrade the old back end structure, to
Click to expand...
the new one. This
can
involve adding, editing, reformatting or deleting data<, as well as
changing table structures & relationships.

By this means, you can distribute a new front-end
Click to expand...
version to any user
(with
any back-end version), & the new front-end will automatically upgrade that
user's back end database to the required new structure.

HTH,
TC


. Reply (E-mail) Forward (E-mail)

Subject: Do I have upgrading choices?
From: "Robert"
Click to expand...
Sent: 3/24/2004 4:35:42 PM




Hello stranger, I appreciate your support!

I have an Access database that I have been perfecting for
5 years now. It does all kinds of administrative tasks
that renders my company administration a breeze. My
database consists of a back end (my tables) and a front
end (my forms). The tables in the back end are linked to
the front end.

However up to now I have been doing modifications on the
actuall database, example adding fields to tables and
fields to forms, modifying fields of their data types in
tables, adding buttons in forms with new code and so
forth.... you know what I mean...

The problem with this is that I am always trying to do
this nights or weekends when no one is using the data
base and when I am finished I recompile everything so
that the next day all the users see the upgraded changes
in the database.

My question is:
Can I copy my database to another machine and do all the
neccessary modifications such as:

1- Adding, deleting or modifying fields and their
properties in tables.
2- Adding , deleting or modifying forms and their
properties.
3- Add VBA code at will.
4- Basically anything I would want to do.

and then sort of quickly upgrade the version that
everyone is using to the new version that I have been
modifying. So basically some sort of a wizard that would
actually have to copy all the data in all tables from the
old database (which includes any new appended data that
my users would have entered while I was working on the
new database) onto the new one but keeping in mind stuff
such as deleting table fields which wouldn't exist in the
new database and so forth.

Basically some sort of way to re-package my new database
with the data of the old database. Ofcourse my new
database's version would be incremented as to show that
this is the new database. But the whole idea is to do my
new database's modifications in peace over days or even
weeks without having to always meet the stressfull
deadline which says [Quote: (I have to make sure that
everything works for tommorrow or I am dead
meat!) :unquote]

I know there is a product called ODE tools, is this the
only way to do what I have explained.

Thanking you in advance for any suggestions, tips or
reccomendations.

Robert
.
Click to expand...


.
Click to expand...
Click to expand...
 
Back
Top