Limited Time Use?

[Hakala]

Hi, Tek-Tippers!

Does anyone know a way to cripple a database after a set amount of time?

I'm having an issue with my user pool saving design copies of a database and running production from them. Since these are DESIGN copies, they aren't complete and in some cases what they "think" is production isn't even close to what they should be getting.

For instance, one design used a lookup table to match records and choose them for display to the user. The lookup table was only filled with a few months' of data, since this was a test version. Yet, I found out yesterday they've been using this database for production stats for over eight months. (The design was scrapped, so the lookup table was never filled in completely.)

I'm trying to find a way to prevent this, and if a design database wouldn't work after a couple of weeks, that would do the trick.

Thanks!

Michelle Hakala

http://www.winebird.com/

 

[mrdenny]

Sorry, there's no way to set a database to expire and become unusable.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog

 

[jrbarnett]

Denny is right in that you can't set one up in a general, but you can implement something that will work for most people:

You need to code some sort of expiry date check in the startup that will display something like:

"This application is for design comments and expired on <date>. This date has now passed. Please contact <details> to obtain an up to date copy."

Another way is to have a current version number in the backend database and check this in the frontend, then display some sort of message at startup and stop it running if they don't match.

I hope though that your users though aren't too tech savvy as it can be quite easy to bypass this if you make it too trivial.

John

 

[ousoonerjoe]

Through a DTS package, can you not pole the Sys tables to determine when the Database was instanciated and then based upon that time, after 30 days fire a DROP Statement? If you can't DROP the database what about dropping the tables within it? No tables, Nothing to pull or update.

Just a thought.

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[Olaf Doschke]

Include some database version number or check out the table structures from system databases. If the test dtabase is a downsized version of the real database you surely can determine that by comparing the expected structure in the application client.

Bye, Olaf.

 

[SQLSister]

I'm with john on what you can do. We did this with an access database I worked with once and if the expired data had passed it would not open until they got the new version.

The other thing to do is to not let anyone except developers have rights on a design database. Our users don't see design databases. They can see QA to test changes, but they don't load QA to their desktop.

"NOTHING is more important in a database than integrity." ESquared

 

[Hakala]

Thank you all!

Based on your comments and talking to another database designer here on site, this is what we did:

* Created a lookup table containing a single date
* Created a form containing two date fields: today and the date from the lookup table
* Added OnOpen code to the form to check the two dates, then if "today" was the greater of the two, quit the application and if not, close the form
* Added opening this form first in the already-present Autoexec macro

It works beautifully. It's easy to get around, but if the users had any database skill, they'd create their own instead of asking me to do it.

Michelle Hakala

http://www.winebird.com/