[AccessD] 64-but ONLY front end ?

[Ryan W]

James, My reply (above) shows I am monitoring with a function inside of
Access that returns the amount of Virtual Memory used by MS Access at the
time.  Unfortunately 32 bit programs on 64 bit OS's are limited to 2GB of
Virtual Memory.  I'm hitting about 1.4-1.5GB used before resource errors
come up. I assume the gap between that number and 2GB is OS/APP overhead.



On Fri, Jan 6, 2017 at 6:43 AM, James Button <jamesbutton at blueyonder.co.uk>
wrote:

> I'd start with task manager to monitor the memory usage - all the variants
> in
> the columns you can select
> And - sometimes running Performance monitor - from the tab at the bottom
> of the
> performance tab helps see what is happening.
>
> And - as you need 64 bit windows to run 64 bit office,
> Check on the paging and other systems usage of resources.
> They should be a minimal difference between usage in 32 and 64 bit office -
> BUT 64 bit windows does seem to want a more memory for itself than the 32
> bit
> version, - minimum of 1GB for the 64 bit OS, and then the app gets what's
> left
> after video, cache, and other system allocations.
>
> OK - I have not used 64 bit Access - but the 'theory' should be the same
> as for
> Excel - mostly petty annoyances - once you have recognised them.
> Setup your app for 64 bit mode and use the 64 bit mode references as in
> dll's
> API's and other code - such as the SQL and comms facilities.
>
>
> JimB
>
>
> -----Original Message-----
> From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> Jim
> Dettman
> Sent: Friday, January 6, 2017 11:53 AM
> To: 'Access Developers discussion and problem solving'
> <accessd at databaseadvisors.com>
> Subject: Re: [AccessD] 64-but ONLY front end ?
>
>
> Actually, many forms is not even a good reason.
>
> Nothing in Access for 64 bit is different than the 32 bit version.  All the
> internal constraints are still there (like 2048 table ID's).
>
> The only reason to use 64 bit Office is if you need:
> 1. Very large spreadsheets in Excel
> 2. Very large projects in MS Project
> 3. Very large projects in Visio.
>
>  If you don't need that, then there's no reason to use it and a lot of
> reasons not to (lack of drivers and 3rd party support).
>
>  Microsoft still recommends 32 bit for just about everyone and
> unfortunately, Ryan is on the bleeding edge, because very few are using 64
> bit because of the above.
>
> Jim.
>
>
> -----Original Message-----
> From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> Charlotte Foust
> Sent: Friday, January 06, 2017 01:10 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] 64-but ONLY front end ?
>
> IMO that's a pretty poor reason to go to 64-bit Office.  If the design were
> better, you wouldn't need a bazillion forms open simultaneously.
>
> Charlotte Foust
> (916) 206-4336
>
> On Thu, Jan 5, 2017 at 7:39 PM, Ryan Wehler <wrwehler at gmail.com> wrote:
>
> > Hello Listers!
> >
> > Has anyone migrated their app to 64 bit only?
> >
> > I've recently started migrating from Office 2003 to Office 2013 (what we
> > have licensed). I've been testing and upgrading and learning about
> ribbons
> > and finding code that doesn't work well under 2013 that worked
> previously.
> >
> > The one problem I'm consistently running into is if I have more than a
> > couple forms open I start getting "Resource Limit Exceeded" messages.
> From
> > what I gather, this is usually the 32 bit Virtual Memory limit (2GB)
> > running 32 bit applications on a 64 bit operating system.
> >
> > If I run Access 2013 64 bit (In a virtual machine) I can open as many
> tabs
> > as my heart desires (I opened so many forms up in my app that my tab bar
> > had scroll arrows!) and not a peep about resource problems.
> >
> > I did some of the stuff suggested out on the web like make sure objects
> > get closed and set to 'nothing' when they aren't needed (which there
> > weren't many places that wasn't happening anyway)... and even tried
> running
> > msaccess.exe in XP compatibility mode (which was what someone suggested
> to
> > get around this).
> >
> > Access 2013 is fully patched and I've tried a number of hot fixes and
> > registry tweaks posted by both MS and other users on the web to no avail
> as
> > well.
> >
> > None of that's worked... so I'm debating moving my users in house (the
> > only place I have to support) to 64 bit Office or Access runtime where
> > applicable. I've already modified all my API calls to to be PtrSafe and
> > kept some compiler constant if/then/else statements in place in case I
> > *HAVE* to run 32 bit somewhere (but then I'll need a way to compile the
> 32
> > bit accde file... *sigh*)
> >
> > In short / TL;DR: Has anyone moved exclusively to 64 bit and what
> problems
> > did you face and are you happy overall with doing so?
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>