Migrating to 64 bit access db solution
in [Help]
|
From: Yuval Nir on 24 Jan 2010 14:51 On Jan 23, 6:26 pm, "David W. Fenton" <XXXuse...(a)dfenton.com.invalid> wrote: > Banana <Ban...(a)Republic.com> wrote innews:4B5A2090.2050901(a)Republic.com: > > > I had a nasty surprise few > > weeks when I used a API and found that it no longer works in > > Vista/Win7/Win2008 family, due to UAC and had to use a completely > > different API. > > Someone posted a while back about the change in the API that returns > the location for where you're supposed to put writable application > components. That used to be in All Users\AppData, but now that > folder is read-only, so there's no place to put writable application > data that can be shared between users. > > That's unfortunate for Access apps, but not disastrous. > > > I think back then we were fortunate to be able to ride > > the coattail of VB developers who needed APIs far more than Access > > developer (no hard fact to back this up, just an haphazard guess > > on my part). This is something we'll have to think about, I would > > imagine. > > Yes, it's an unfortunate fact that we seem to be left behind. I > assume MS has a plan for that and that we'll be getting some form of > .NET sometime in the future. I'm not excited about that, but it's > going to be a necessity if Access is going to maintain its > capability for infinite expandability. > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ OK. I played a little and modified API. Problems partially resolved. And, BTW I decompiled the db as well. One major issue is that after correcting the calls with Ptrsafe and longptr, the vba code compiled and the database was working. However, trying to modify the code and recompiling, generated errors such as "The database cannot be opened because the VBA project contained in it cannot be read"," out of memory"... So vba compiling process did not detect errors, which later prevented code reading. Placing the database on a 32 bit office, worked just fine. One of the main error generated was S. Lebans Magnifier and his module Mod Mischstuff- I saw he retired from all access activity- what a shame! He had some cool stuff... and was one of the key solution solvers. So for now I removed those elements from the data base. Looks like things are working and code can be read. But- Acccess is unable to create and ACCDE... NO error details. From my experience, this is usually due to VBA error. But at this point, I cannot find any and the database compiles just fine. If I try it on the 32 bit environment- it works and creates the AccDE. I assume I should just continue this thread as it all relates to 32-64bit migration. Thanks. yn
From: David W. Fenton on 24 Jan 2010 19:22
Yuval Nir <ynthevet(a)gmail.com> wrote in news:14935d12-69f0-4e75-a4ff-79301f37a0b8(a)o28g2000yqh.googlegroups.co m: > So for now I removed those elements from the data base. Looks > like things are working and code can be read. But- Acccess is > unable to create and ACCDE... NO error details. From my > experience, this is usually due to VBA error. But at this point, I > cannot find any and the database compiles just fine. If I try it > on the 32 bit environment- it works and creates the AccDE. That sounds like you've still got 32-bit API calls (assuming you're trying to create the ACCDE on 64-bit windows). I really think conditional compilation is the only way to go, since then the same codebase can be compiled to MDE/ACCDE on either 32-bit or 64-bit windows (though the resulting MDE/ACCDE will be limited to one or the other platform). -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |