From: Eduardo on 14 Nov 2009 13:38 Ralph escribi�: > You have run into the "object lifecycle" differences between DAO 3.5 and 3.6 > I alluded to in another post. Ralph, I'm also interested on this subject. Because as I said, I didn't notice any problem so far, but my program in some client's scenarios uses the database concurrently, I mean: different instances of my program could run on different machines and accesing the same database at the same time. It's an Access 97 database. So, one person can be working on one machine and another person could be working in other machine at the same time. And it worked all OK with DAO 3.51. And I still didn't test that with DAO 3.6. If I switch back to DAO 3.51 what problem can I encounter? I changed to DAO 3.6 because I upgraded the program from VB5 to VB6 and because I had problems (en error) when the installer of the VB5 version attemped to install the DAO 3.51 dll on Vista. Thanks.
From: Tony Toews [MVP] on 14 Nov 2009 17:26 "Ralph" <nt_consulting64(a)yahoo.com> wrote: >And of course I'm in love with my own answer: >"If it ain't broke, don't fix it." Hehehehe Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a free, convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Marc Henderson on 15 Nov 2009 08:41 "Ralph" <nt_consulting64(a)yahoo.com> wrote: > >"Marc Henderson" <genesis77Re-move-this(a)usa.com> wrote in message >news:qbdtf5petf2is2s76d6c6963e8n2p7uj8f(a)4ax.com... >> "Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote: >> >> I tried removing the reference to DAO 3.51, and replacing it with 3.6 >> and had a number of odd experiences. The database appears to work >> fine, navigating from record to record works as expected, etc. Then I >> tried one of our menu commands: Compact Database. The result was >> Err 3356: You attempted to open a database that is already opened >> exclusively by user 'admin' on machine 'SERVER4' ... >> ><snipped> >> >> Similar experience when running Form1_Unload: >> CloseDB, didn't close the db and left an ldb file lying around. >> >> Plus more oddities that don't seem to be *remotely* related to any db >> code. >> > >You have run into the "object lifecycle" differences between DAO 3.5 and 3.6 >I alluded to in another post. > >It has been awhile since I fought these wars, so it will take me time to go >back to my notes ... in the meantime, it will be helpful if you will publish >the exact data control/s, the connectionstring or method you are connecting >with IF different from the default Jet, and the specific Jet file format you >are working with. Hi Ralph, Our app saves web pages and page text. It's an MDI app and you can view a saved page in the WebBrowser control and saved text in an rtb. We use a Data control and a DBList control. and numerous other non-db-related controls. We don't use a connection string. I just read a MS KB article about converting Access 97 to Access 2000 (DAO 3.51 to 3.6) and I solved the problem of not being able to close the db or do a compact. It was the connect property in the data control, which was previously 'Access'. When I selected 'Access 2000', it finally could close the db and do a compact, although it took about 5 times longer than it had with Access 97. > >You can get the control information from the .vbp file. > >Also be aware that the changes you will have to make are mostly structural - >ie, you will just have to re-arrange your code and/or insert a new line here >or there. It is possible you may need to swap controls (which can be done >using a text editor). But nothing else more exotic will be necessary. ie, >DON'T PANIC. lol > >-ralph > There are still oddities however and most of them have nothing to do with our db code. I hope we don't have to make extensive code changes, since we had hoped to get our new release out soon. I'm not entirely convinced that I want to make the switch to DAO 3.6 because, as you pointed out, 'if it ain't broke, don't fix it'. It's just that MS statement that 'DAO350.dll isn't supported' makes me uneasy. What if Win7 evolves into something that really won't support DAO350.dll. Thanks a lot for your help (and everybody else's). If you come across anything that may be of interest, I'll be watching this thread for a long time. <g> Marc h
From: Ralph on 17 Nov 2009 15:38 "Eduardo" <mm(a)mm.com> wrote in message news:hdmtf5$eke$1(a)aioe.org... > > If I switch back to DAO 3.51 what problem can I encounter? > I changed to DAO 3.6 because I upgraded the program from VB5 to VB6 and > because I had problems (en error) when the installer of the VB5 version > attemped to install the DAO 3.51 dll on Vista. > Sorry, for the delay, been away for a bit. I went back and checked my notes, and apparently what I remembered about 'conversion issues' were pretty much confined to the initial releases. Just about everything has been 'repaired' or 'corrected' with subsequent VB SPs and Jet Packages. i.e., don't apply that much any more. That is why I really wanted to know more about the OP's environment. If you are using the latest 'n greatest Jet Packages and SPs, you should not experience any difficulties in making the switch. However, I can see there may be still some issues with VB5 and VB5 DAO controls. But I haven't used VB5 in years so wouldn't know. I do know that clients that are still using DAO 3.51 with various in-house programs seem to work just fine in Vista - once as you said - one gets over the hump of installing the older DAO suite. (The easiest way to manage that is just bundle the DAO 3.5 stuff into its own install package, ie, no OLE junk.) As an aside to the robustness of DAO, I even have one client that includes DAO 3.5, DAO 3.6, translation dlls, and ADO 2.5 all within the same applications. Gives me the shudders - but they are happy. <g> -ralph
From: Eduardo on 17 Nov 2009 17:33
Ralph escribi�: > "Eduardo" <mm(a)mm.com> wrote in message news:hdmtf5$eke$1(a)aioe.org... >> If I switch back to DAO 3.51 what problem can I encounter? >> I changed to DAO 3.6 because I upgraded the program from VB5 to VB6 and >> because I had problems (en error) when the installer of the VB5 version >> attemped to install the DAO 3.51 dll on Vista. >> > > Sorry, for the delay, been away for a bit. > > I went back and checked my notes, and apparently what I remembered about > 'conversion issues' were pretty much confined to the initial releases. Just > about everything has been 'repaired' or 'corrected' with subsequent VB SPs > and Jet Packages. i.e., don't apply that much any more. That is why I really > wanted to know more about the OP's environment. > > If you are using the latest 'n greatest Jet Packages and SPs, you should not > experience any difficulties in making the switch. OK, thank you. > > However, I can see there may be still some issues with VB5 and VB5 DAO > controls. But I haven't used VB5 in years so wouldn't know. I do know that > clients that are still using DAO 3.51 with various in-house programs seem to > work just fine in Vista - once as you said - one gets over the hump of > installing the older DAO suite. (The easiest way to manage that is just > bundle the DAO 3.5 stuff into its own install package, ie, no OLE junk.) My VB5 installer was the one generated by the VB5 PDW. On Vista it throws an error that it cannot install some DAO 351 dll, and if you ignore the error, you can't run the program once installed. One customer told me that he managed to install it by installing DAO from an MS download, but I didn't pay much attention because that's not an option that I even consider (to tell to the people to ignore the error, then to install something else, etc). The VB5 program also needs UAC disabled, so I just tell that the current version is not Vista compatible and to wait for the new version. > > As an aside to the robustness of DAO, I even have one client that includes > DAO 3.5, DAO 3.6, translation dlls, and ADO 2.5 all within the same > applications. Gives me the shudders - but they are happy. <g> > > -ralph > > > |