How to tell Access Version (Access 97 (SP2))

Topic

New Reply

I’m testing out a new software product and, among other annoying things, they have an .mdb database that is password protected. If we’re running Access 97, open the db and a password window comes up, is it safe to say that this is an A97 database?

The reason for my (probably dumb ) question is because I have to document all A97 databases for our impending move up the MS chain to a brand new version of Office (haven’t decided which one yet). We don’t want this software to crash and burn when we do (nor do we want to fork out more bucks for “conversion”).

Reply | Quote

Replies

You don’t indicate whether the password dialog is the one for user security or that for a database password. If it’s the former it doesn’t mean it is Access97, as the user security password us collected before you attempt to open the database. If it’s a database password, then there’s an excellent probability that it is an Access97 database, as it has to start the file open to know a password is required. In any event 2000 and 2002 can open and run a 97 database, but you can’t make any design changes. Hope this helps.

Reply | Quote

Sorry – it appears to be a database password. When I got home, I remembered that when you open an A97 in A2K, that it won’t let you save anything unless you convert it to A2K. My peeve is that they told us we could run reports off the .db, but obviously not, if you need a password to get in and it’s not available. .

Thanks, Wendell!

Reply | Quote

It might be worth taking a look at thread starting with post 144842

HTH

Peter

Reply | Quote

Thanks, Peter – interesting thread….I mentioned the cracker to my boss earlier (I already know about Bokler), but we didn’t think this was an ethical way to go. I keep hoping that the tech I’m working with at the third party software place will give me a hint.

Reply | Quote

Is it a split database, with a front-end and a back-end? If so, you might be able to attach to the tables in the 97 database and create and run reports using a 2000 front-end. We don’t usually recommend that approach for production stuff because of performance issues. If it’s a database password, then someone would need to know the password to use it to begin with, so knowing the password should let you open it and inspect objects and what not – you just can’t make design changes. Hope this helps.

Reply | Quote

Sadly, Wendell, it’s just one big happy expanding db. Clearly, if we’re going to use this, we’ll have to have a way to compact and repair, particularly as we anticipate using this third party application for a lot of processing. I find it a bit odd that they would password protect this in the first place other than a ploy to charge us more for the password.

Reply | Quote

It does seem very strange to use a database password in that fashion – how is it that you can open the application normally without getting a password prompt? Do you get the password prompt if you attempt to link to tables?

Reply | Quote

The software package must supply the password to the underlying Access database some way….

And yes, if I open a new A97 db and try to link the tables from this database, it asks me for the password. If I could link the tables just to do reports, we wouldn’t have a problem(other than maintenance). The software package doesn’t let the user set up new reports. Also, one of the reports that is supplied in the pkg truncates some information we need, so it would be nice if we could “tweak” the report so that I don’t need to manually write this stuff down.

Reply | Quote

This is third party software. You cannot reasonably expect to document that database yourself unless the vendor has turned over the keys to the kingdom. You do NOT have the right to open that database just because someone wants you to unless you bought that right when you bought the software. Moving to a new version of Office has nothing to do with it unless in fact you are using an *installed* version of Access to run this app rather than a runtime installation or an executable that incidentally uses an Access backend. The logical and ethical thing to do is get the information from the vendor. It is not a case for a cracker because this is not an abandoned application, this is a situation where you have a current vendor and you want to investigate his product beyond the limits the vendor permits. The password is clearly there to keep you from messing about in the application. I would do the same thing with my apps because I don’t want anyone exploring them either!

Reply | Quote

I totally understand, Charlotte – my concern lies mainly with the routine maintenance one has to do to Access 97 to keep everything running smoothly (compacting and repairing). It is impossible to do either to this db, and we may abandon this third party software as a result, since their software does not appear to allow for this type of maintenance without it costing the end user support bucks to do so.

Reply | Quote

If the developer did not handle this within the application either behind the scenes or with user controls, then you *should* abandon the application. However, are you quite sure the application isn’t taking care of this for itself? Most of the compacting and repairing in 97 is needed on the front end where the queries are being run. If the front end of the application is not in Access, then it isn’t something you should concern yourself with anyhow. If it is an Access front end, then find out from the developer how this is being handled.

Reply | Quote

Since I can’t “see” the database, I don’t know where the report is coming from that we need to tweak although the output looks suspiciously like Access. We’re currently having other problems with them as well involving some network configuration so it doesn’t look promising. With all the time we’ve taking testing this out, conferring with their support group and generally discussing the situation, I could have whipped something up in A2K (or VB or something) that would work lots better.

Kinda frustrating….

Reply | Quote