From: Eduardo on
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
"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
"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

"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
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
>
>
>