Suggestions on keeping track of updates

[Montez659]

Well, it seems that as the db grows, so do the number of forms, queries, and reports in use. Such is life and I wouldn't have it any other way.

However, the downside is that sometimes a few weeks can occur before I am ready to push another update. Right now, I basically load the interface up manually on the user's computers, but I have been checking out the auto updaters available.

Currently, in addition to an Admin, User, and Read-Only interface on my computer that I update, I also have a Production interface where I can do all my work and test stuff before updating. Sometimes in the sea of confusion surrounding bugs, updates, requests, etc., I have a hard time keeping track of what I need to copy from my Production interface to the Admin, User, and Read-Only interfaces.

So I am looking for suggestions. I was trying to think through a way to maybe label each form (hardcoded?) or I guess maintain a seperate table with each table, form, query, macro name and the last time it was updated, and whether it would need to be pushed to the update files.

Any thoughts on what you do and the best way to keep organized?

 

[CharlesChuckieCharles]

Use a source control product

 

[Montez659]

And that means?

 

[CharlesChuckieCharles]

something Like Microsoft Sourcesafe (if its still around) but scan the internet for source control products, you'll find a fair few

The other way is to prioritise the developments and don't start the next before the current is live
(probably impractical)

 

[Montez659]

I appreciate the suggestion, but this seems like overkill for what I am working on. I don't even work in the IT dept, let alone have access to d/l and install on my workstation. I work within a department that I simply (hah!) built a db for, and am looking for a good method to help me manage it.

Any other suggestions out there? Not necessarily looking for a product, but just some ideas on how others go about it.

 

[SydneyGeek]

Some ideas:

1. Once you have a stable, tested version, promote that to production (make a straight copy) and adjust for read-only etc.
2. You can list the creation / modification date of all objects. Use this to decide which to copy over (you will need a record of the last time you released a new version)

If you're worried about the hassle of pushing new front ends out to all your users take a look at Bob Larson's utility for automating the process.

Denis

 

[SydneyGeek]

Just thinking... Do you have 3 different front ends for the different access / permission levels? If so, how do they differ?
It's possible (without going into User Level Security) to control permissions in just one database, using the Windows login, a table or two, and a main menu form. Could simplify your life.

Denis

 

[Montez659]

I do have three different front ends, but it is really not that big of a deal updating them now, nor do I presume that it will be in the future. I kind of have an idea of where you were going, but I haven't played around with it enough to feel comfortable doing it, not to mention that there are a few things that I need to learn first.

Right now, I think the Admin interface has two extra tables and about 6 extra reports that the User interface didn't have, so it's not too bad right now.

As far as the OP, I basically created a table with the name of each elemement (table, report, query, etc.) and a column for if it applies to User, Admin, or Read Only interface, and then the last update Date field, and a Yes/No for whether it needs to be updated or not. I can then just generate a quick report or query to see which forms, reports, queries that I need to copy.

Thanks for all the brainstorming guys!