Dao350.dll unsupported under Windows 7
in [Visual Basic]
|
From: Jason Keats on 13 Nov 2009 09:56 Ralph wrote: > "Jason Keats"<jkeats(a)melbpcDeleteThis.org.au> wrote in message > news:uxmOR5FZKHA.2184(a)TK2MSFTNGP04.phx.gbl... >> Tony Toews [MVP] wrote: >>> But what about possible security vulnerabilities with Jet 3.5? >>> Highly unlikely I agree but I wouldn't want to run that risk. There >>> have been some vulnerabilities patched with Jet 4.0. It's quite >>> possible those vulnerabilities exist in Jet 3.5 and, if so, they have >>> not been patched. >>> >>> Tony >> >> You probably know that DAO 3.5x supports Access 97/Jet 3.5, while DAO >> 4.0 supports Access 2000/Jet 4.0. >> >> The main difference being unicode support and the ability to use ADO. >> >> Although DAO is a bit faster and allows you to modify the database, it's >> not as flexible, or as much fun, as ADO. ADO, of course, was the future >> (until ADO+/ADO.NET). >> >> According to some it also got a little slower because unicode strings >> are twice as long. >> > > Gentlemen, I fully believe that both of you are sincere and have the OPs > "best interest" at heart. But here are the significant facts: > > 1) DAO 3.5 uses Jet 3.5 and is recommended for use with Jet 3.5 formatted > databases. > 2) DAO 3.6 uses Jet 4.0 and is recommended for use with Jet 4.0 formatted > databases. > 3) Both DAO 3.5 or DAO 4.0 data access libraries can be used on Win7. > 4) However, we don't know for sure what the OP's targeted file format is. > The fact that some clients are using "DAO 3.1" *suggests* that some clients > may be using a file format older than 4.0, but we don't know for sure. > 5) We also don't what controls the OP's application might be using. (Some VB > and 3rd party controls have a dependency on a specific DAO version.) > 5) If the OP needed improved support for Jet 4.0 file formats or controls - > that fact would have appeared before now - NO matter what O/S the OP was > targetting. > 6) The OP reports that preliminatry tests show that there is no problem > using DAO 3.5 with his application. > > I fully agree that using the Latest 'n Greatest of just about anything is of > ten the way to go - especially with a technology that is some ten plus years > old. In this case, for example, the OP would gain: > 1) Not having to distribute the Jet 3.5 components with newer platforms. > 2) Availability of security patches. > 3) Better support (more optimal) for Jet 4 file formats, and > 4) some advantages in using the Jet 4 engine. > But then the OP also runs the risk of: > 1) introducing subtle bugs into the application. DAO 3.6 manages lifecycles > a bit differently. (Nothing that can't be repaired with a little > re-organization.) > 2) introducing a possible reduction in performance, > 3) no longer being able to work with older Jet formats, and > 4) possibily breaking existing client solutions > (This latter is more often a problem if the client is using more than one > tool for manipulating the database file.) > > Perhaps the gains out-weight the risks? But we don't know. That is up the OP > to test and decide. In the meantime - quite frankly - if it ain't broke, why > *fix* it? > > -ralph > > I don't disagree with anything you say, Ralph. And, of course, I meant DAO 3.6, not 4.0. All I would add is that if I had the choice of using DAO or ADO, I'd probably pick ADO any time (unless I had to generate the .mdb file via code). Happy coding.
From: Jeff Johnson on 13 Nov 2009 11:28 "Jason Keats" <jkeats(a)melbpcDeleteThis.org.au> wrote in message news:%23EADUGHZKHA.736(a)TK2MSFTNGP06.phx.gbl... > All I would add is that if I had the choice of using DAO or ADO, I'd > probably pick ADO any time (unless I had to generate the .mdb file via > code). Not I. If I were going to be doing anything but pure data manipulation (CRUD), I'd use DAO over ADO any day. If I have to create tables, queries, or any object in an MDB, I far prefer using TableDefs et al. over CREATE TABLE statements or whatnot. I'm not saying I'm against SQL (I use it all the time), but I like the DAO object model when dealing with, well, objects!
From: Jeff Johnson on 13 Nov 2009 11:29 "Marc Henderson" <genesis77Re-move-this(a)usa.com> wrote in message news:ascpf55i70nd6lcm5sms8av5peunj1e6it(a)4ax.com... > The funny thing is the old dao350.dll, etc. seem to work well with our > app on Win7 RC, but the word "unsupported" is a little discouraging. "unsupported" <> "does not work" "unsupported" = "we won't be fixing any bugs in it ever again"
From: Ralph on 13 Nov 2009 13:42 "Jason Keats" <jkeats(a)melbpcDeleteThis.org.au> wrote in message news:%23EADUGHZKHA.736(a)TK2MSFTNGP06.phx.gbl... <snipped> > > All I would add is that if I had the choice of using DAO or ADO, I'd > probably pick ADO any time (unless I had to generate the .mdb file via > code). > As you and Jeff noted DAO has clear DDL advantages over ADOX (ADOX was added later when ppl complained about no DDL features in ADO - but it is very definitely a hasty implemented less-functional library than DAO's) DAO also has a clear performance advantage over ADO when using "CRUD" on a desktop with a Jet-formatted database. It also works better with some databases that supply a native ODBC client, such as AS/400. It is only when using a database in a distributed multi-user environment, or when using OLE DB controls or data-aware classes, does the advantages of using ADO kick-in. [It is interesting to note, that MSAccess's new ACE is actually Jet/DAO+ and not anything "ADO-ish". So much for the DAO model being ancient technology. <g>] -ralph
From: Tony Toews [MVP] on 13 Nov 2009 15:34
"Ralph" <nt_consulting64(a)yahoo.com> wrote: >Gentlemen, I fully believe that both of you are sincere and have the OPs >"best interest" at heart. But here are the significant facts: > >1) DAO 3.5 uses Jet 3.5 and is recommended for use with Jet 3.5 formatted >databases. >2) DAO 3.6 uses Jet 4.0 and is recommended for use with Jet 4.0 formatted >databases. Recommended by Microsoft but as pointed out in my previous posting this isn't a big deal. Jet 4.0 can work with Jet 3.5/A97 format MDBs just fine. >4) However, we don't know for sure what the OP's targeted file format is. >The fact that some clients are using "DAO 3.1" *suggests* that some clients >may be using a file format older than 4.0, but we don't know for sure. >5) We also don't what controls the OP's application might be using. (Some VB >and 3rd party controls have a dependency on a specific DAO version.) >5) If the OP needed improved support for Jet 4.0 file formats or controls - >that fact would have appeared before now - NO matter what O/S the OP was >targetting. >6) The OP reports that preliminatry tests show that there is no problem >using DAO 3.5 with his application. No arguments there. >I fully agree that using the Latest 'n Greatest of just about anything is of >ten the way to go - especially with a technology that is some ten plus years >old. In this case, for example, the OP would gain: Well, Jet 4.0 isn't the latest'n greatest. <smile> >But then the OP also runs the risk of: >1) introducing subtle bugs into the application. DAO 3.6 manages lifecycles >a bit differently. (Nothing that can't be repaired with a little >re-organization.) What do you mean by lifecycles? >2) introducing a possible reduction in performance, And yet another poster states it has better performance in some situations. >3) no longer being able to work with older Jet formats, and Access 2000 can update A2.0 format MDBs just fine. So Jet 4.0 can update A2.0 MDBs. >4) possibily breaking existing client solutions >(This latter is more often a problem if the client is using more than one >tool for manipulating the database file.) Only if the clients tools are A97 or older. Which at this point they should be well past and at least in the 2003 time frame again due to security vulnerabilities. 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/ |