g_epley
asked on
(AppName) has caused an error in DAO360.dll
Encountering a strange problem on Windows 98 and ME systems with a database error.
I have done a lot of MS Access database projects, using either Access 97 or 2000 databases and DAO. Never had this problem before.
The only difference with this app is that it needs to reference two different database files, one for the existing (old) database, which is Access 2000, and the new database, which I've tried both Access 2000 and 97 formats on. This is a conversion process to convert data and populate the new database without the need to hand type all the data. Also different with this project is password protection on the new database file and encryption on the new database file (neither of these exist on the old Access 2000 .mdb file).
The whole project runs fine on the 98/ME systems if VB6 is installed, so I know that VB6 is installing something that's making the app happy.
MDAC version is irrelevant, since the app runs fine so long as VB6 is installed. All the runtimes and JET support I've used on previous projects are being installed.
The error I get is very vague:
(app name) has caused an error in DAO360.dll
This error message is occuring when the conversion tries to access both the old and new database files during the conversion. I can't be more specific than that, because I can't get the error to occur once VB6 is loaded on the machine for debugging, and I doubt a text debug file would point me to the problem.
This error message has a close button. No error numbers or anything. Stumped. Can't find any mention of this error anywhere.
It has been suggested to me that some database update files need to be installed on the system. Unfortunately the person who told me this can't specify what files, so that's no help.
Clearly, I've established that VB6 is installing something that allows the app to run okay, so I'm hoping someone experienced with DAO and the facts above can steer me in the right direction. The only thing I have left to try is to remove any reference to the password and also decrypt the new database and see if that helps any. However, I do need to password protect and encrypt the data for safety, and the fact that the app runs fine so long as VB6 tags along tells me this should not be something I must give up. ADO is also not an option, as again, something installed with VB6 is allowing this to run, so it's not a case of ADO vs. DAO or anything like that.
I'm very frustrated by this vague error which has ground this whole project to a halt. My last remaining option is to investigate another type of database the client can use that's not going to cost them much, if anything, and something that VB6 can address without my having to make too many changes to the existing project in order to roll it in. However, before I dive into that I'd like to better understand how to fix this problem, as there's got to be a solution other than what I'm considering.
I have done a lot of MS Access database projects, using either Access 97 or 2000 databases and DAO. Never had this problem before.
The only difference with this app is that it needs to reference two different database files, one for the existing (old) database, which is Access 2000, and the new database, which I've tried both Access 2000 and 97 formats on. This is a conversion process to convert data and populate the new database without the need to hand type all the data. Also different with this project is password protection on the new database file and encryption on the new database file (neither of these exist on the old Access 2000 .mdb file).
The whole project runs fine on the 98/ME systems if VB6 is installed, so I know that VB6 is installing something that's making the app happy.
MDAC version is irrelevant, since the app runs fine so long as VB6 is installed. All the runtimes and JET support I've used on previous projects are being installed.
The error I get is very vague:
(app name) has caused an error in DAO360.dll
This error message is occuring when the conversion tries to access both the old and new database files during the conversion. I can't be more specific than that, because I can't get the error to occur once VB6 is loaded on the machine for debugging, and I doubt a text debug file would point me to the problem.
This error message has a close button. No error numbers or anything. Stumped. Can't find any mention of this error anywhere.
It has been suggested to me that some database update files need to be installed on the system. Unfortunately the person who told me this can't specify what files, so that's no help.
Clearly, I've established that VB6 is installing something that allows the app to run okay, so I'm hoping someone experienced with DAO and the facts above can steer me in the right direction. The only thing I have left to try is to remove any reference to the password and also decrypt the new database and see if that helps any. However, I do need to password protect and encrypt the data for safety, and the fact that the app runs fine so long as VB6 tags along tells me this should not be something I must give up. ADO is also not an option, as again, something installed with VB6 is allowing this to run, so it's not a case of ADO vs. DAO or anything like that.
I'm very frustrated by this vague error which has ground this whole project to a halt. My last remaining option is to investigate another type of database the client can use that's not going to cost them much, if anything, and something that VB6 can address without my having to make too many changes to the existing project in order to roll it in. However, before I dive into that I'd like to better understand how to fix this problem, as there's got to be a solution other than what I'm considering.
ASKER
So you're saying then that I can't access both an Access 2000 and Access 97 database at the same time in the same project?
Only problem with this logic is that, as I pointed out in the post, the app runs fine on any system I install VB6 on. Everything about the project runs fine. I tested this with a mix of 97/2000 and both database files on Access 2000 - in both cases, on any system, XP, 98 or ME, so long as VB6 is installed - no problems. This even works running the compiled exe, not just in the runtime environment (design).
There could possibly be one or more support files, along with proper registration of those files in Windows, going on here. Unfortunately no one's been able to point out those files or tell me what to register if anything. I considered the DAO 3.51 issue and references in the VB6 project, but since the project runs fine within the design environment and as a compiled exe on any system with VB6 installed, my gut feeling tells me that installing VB6 provides some support files that are allowing the app to do what it needs to do. As I mentioned in my post, I am not a newbie at these database projects; I've done both 97 and 2000 projects and never encountered this vague error. The big difference in this project is really the password and the encryption which are both set within the Access database. I would also really consider taking both of those out but it seems a stupid thing to take them out when they work fine so long as VB6 is installed on the system in question.
I'd really prefer to just stay with an Access 2000 level anyway; the only reason I tried Access 97 in the mix was to try to isolate the problem. Unfortunately, the problem doesn't seem to be whether I'm using 97 or 2000 or even a mix, but rather something Microsoft installs with VB6. If one could find out what's happening there, one could supply the files during install. Microsoft is really bad about this area of providing redistributable files in a convenient manner when it comes to DAO and older technologies, but if I can figure out the files I'll just make my own setup fixes whether Microsoft likes it or not. After all, they created the problem, I'm just trying to make it work like it should.
Only problem with this logic is that, as I pointed out in the post, the app runs fine on any system I install VB6 on. Everything about the project runs fine. I tested this with a mix of 97/2000 and both database files on Access 2000 - in both cases, on any system, XP, 98 or ME, so long as VB6 is installed - no problems. This even works running the compiled exe, not just in the runtime environment (design).
There could possibly be one or more support files, along with proper registration of those files in Windows, going on here. Unfortunately no one's been able to point out those files or tell me what to register if anything. I considered the DAO 3.51 issue and references in the VB6 project, but since the project runs fine within the design environment and as a compiled exe on any system with VB6 installed, my gut feeling tells me that installing VB6 provides some support files that are allowing the app to do what it needs to do. As I mentioned in my post, I am not a newbie at these database projects; I've done both 97 and 2000 projects and never encountered this vague error. The big difference in this project is really the password and the encryption which are both set within the Access database. I would also really consider taking both of those out but it seems a stupid thing to take them out when they work fine so long as VB6 is installed on the system in question.
I'd really prefer to just stay with an Access 2000 level anyway; the only reason I tried Access 97 in the mix was to try to isolate the problem. Unfortunately, the problem doesn't seem to be whether I'm using 97 or 2000 or even a mix, but rather something Microsoft installs with VB6. If one could find out what's happening there, one could supply the files during install. Microsoft is really bad about this area of providing redistributable files in a convenient manner when it comes to DAO and older technologies, but if I can figure out the files I'll just make my own setup fixes whether Microsoft likes it or not. After all, they created the problem, I'm just trying to make it work like it should.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi Richard,
The reason I said MDAC version is irrelevant (in this case), is that I used Component Checker to check the version on all machines in question. The ME system had v2.5, while XP had 2.7 SP1, yet the app, as I described, runs fine on all systems so long as VB6 is installed. This check was made on systems before and after VB6 install and relevant service pack installation. Therefore, my conclusion - MDAC version IS irrelevant, sorry to correct you, but the facts stand in this case as you can see.
I will check out the DAO360 versions but don't expect that to solve the problem. I will give you the points and a follow up message once I have a chance to check it out and find that it works.
-Greg
The reason I said MDAC version is irrelevant (in this case), is that I used Component Checker to check the version on all machines in question. The ME system had v2.5, while XP had 2.7 SP1, yet the app, as I described, runs fine on all systems so long as VB6 is installed. This check was made on systems before and after VB6 install and relevant service pack installation. Therefore, my conclusion - MDAC version IS irrelevant, sorry to correct you, but the facts stand in this case as you can see.
I will check out the DAO360 versions but don't expect that to solve the problem. I will give you the points and a follow up message once I have a chance to check it out and find that it works.
-Greg
OK;
It is probably then a Jet update. MDAC 2.7 does not update Jet.
checkout
http://support.microsoft.com/default.aspx?scid=kb;en-us;239114
Richard
It is probably then a Jet update. MDAC 2.7 does not update Jet.
checkout
http://support.microsoft.com/default.aspx?scid=kb;en-us;239114
Richard
ASKER
Hi Richard,
Apologies for the late reply, my router was down due to a bad firmware upgrade and I was only able to get the problem resolved and get back on the internet late last night.
Initial testing on the Jet 4.0 versions and applying the files from the article does not appear to solve the problem. I can't be entirely sure of the Windows ME yet because that test system isn't going to be available to me for some time. Initially I was excited by the info in the article because a base XP system did have a SP6 Jet 4 version, while a base XP system with VB6 installed had a SP8 Jet 4 version. The app is still crashing on XP without VB6. With VB6 installed the app runs fine, which is the weird thing.
Since previous apps I've done with Access 2000 version databases have been running fine for some time, I have to assume the root of the problem here is the password protection on the database, and possibly the encryption; this is all set within MS Access by opening the DB in exclusive mode. Once set, the VB6 app has no problems with the DB.
Getting very frustrated with this problem, being stopped like this when the app is ready for testing with the client, all because of this stupid password/encryption stuff I added strictly to try to help protect the security of the client's data. So frustrated with it that I'm considering just dropping it all and investigating other databases to solve the problem. That will likely involve a major rewrite of most of the code, but it seems more time efficient than continuing to run in circles on whatever is causing this current problem.
Unless you have any other thoughts, and since I don't know how long I can leave this question open, I guess I have no choice but to award you the points even though I lack a solution as yet. I haven't seen any way here to cancel a question, which I don't think is right - I mean, if no one can help then I shouldn't be forced to award points for nothing when I posted here to get an answer, but as yet I can't see a way to avoid that.
Apologies for the late reply, my router was down due to a bad firmware upgrade and I was only able to get the problem resolved and get back on the internet late last night.
Initial testing on the Jet 4.0 versions and applying the files from the article does not appear to solve the problem. I can't be entirely sure of the Windows ME yet because that test system isn't going to be available to me for some time. Initially I was excited by the info in the article because a base XP system did have a SP6 Jet 4 version, while a base XP system with VB6 installed had a SP8 Jet 4 version. The app is still crashing on XP without VB6. With VB6 installed the app runs fine, which is the weird thing.
Since previous apps I've done with Access 2000 version databases have been running fine for some time, I have to assume the root of the problem here is the password protection on the database, and possibly the encryption; this is all set within MS Access by opening the DB in exclusive mode. Once set, the VB6 app has no problems with the DB.
Getting very frustrated with this problem, being stopped like this when the app is ready for testing with the client, all because of this stupid password/encryption stuff I added strictly to try to help protect the security of the client's data. So frustrated with it that I'm considering just dropping it all and investigating other databases to solve the problem. That will likely involve a major rewrite of most of the code, but it seems more time efficient than continuing to run in circles on whatever is causing this current problem.
Unless you have any other thoughts, and since I don't know how long I can leave this question open, I guess I have no choice but to award you the points even though I lack a solution as yet. I haven't seen any way here to cancel a question, which I don't think is right - I mean, if no one can help then I shouldn't be forced to award points for nothing when I posted here to get an answer, but as yet I can't see a way to avoid that.
ASKER
Hi Richard,
Sorry for the delay in posting the points.
I, reluctantly at first, decided to do some tests with ADO, first using the ADO control, then following up with doing the same thing in code alone.
The tests seemed to run fine on my main development system, both in the IDE and as an executable, which was encouraging. BTW I installed SP6 for VB6, which was released in late March 2004, just to be on the safe side.
I then copied the relevant files to a stock Windows ME system, taking care to only copy files that an installer would copy. The executable ran without a hitch.
I had converted the entire project over to doing DAO with code, so the changes to ADO, based on everything I've tried so far, will be minimal. At least I know if I have any problems at this point that a MDAC update will likely fix the problem.
Anyway, thanks for your help and I'm awarding you the points because the info you provided was all helpful in one way or another, and after all I did say in my original post I was wanting to avoid ADO, so you wouldn't have suggested that as a result. I was exposed to a lot of bad info on the internet and in the MS examples on ADO, but fortunately have found some better resources which have helped me greatly simplify the process. Overall I'm impressed with ADO and will be using it for my database projects from this point forward.
-Greg
Sorry for the delay in posting the points.
I, reluctantly at first, decided to do some tests with ADO, first using the ADO control, then following up with doing the same thing in code alone.
The tests seemed to run fine on my main development system, both in the IDE and as an executable, which was encouraging. BTW I installed SP6 for VB6, which was released in late March 2004, just to be on the safe side.
I then copied the relevant files to a stock Windows ME system, taking care to only copy files that an installer would copy. The executable ran without a hitch.
I had converted the entire project over to doing DAO with code, so the changes to ADO, based on everything I've tried so far, will be minimal. At least I know if I have any problems at this point that a MDAC update will likely fix the problem.
Anyway, thanks for your help and I'm awarding you the points because the info you provided was all helpful in one way or another, and after all I did say in my original post I was wanting to avoid ADO, so you wouldn't have suggested that as a result. I was exposed to a lot of bad info on the internet and in the MS examples on ADO, but fortunately have found some better resources which have helped me greatly simplify the process. Overall I'm impressed with ADO and will be using it for my database projects from this point forward.
-Greg
Leon