[AccessD] 64-but ONLY front end ?

[Jim Dettman]

 Well it sounds like you need to move to 64 bits then, but in the end that
may or may not help.

 As far as I'm aware, Access still has  all the same internal constraints
that 32 bit does, the biggest of which in this situation is no more than
2048 table ID's at once.   That limits the number of things you can have
open.

 I'm not sure though that's a hard limit as it seems to float a bit.
Sometime you seem to get a little more, sometimes a little less.   I believe
Access uses an internal heap to track table ID's and it uses what available
memory is left to mange that.  On 64 bit, you may get more out of it.

 But as far as who's used 64 bit, there are *very* few (I would say almost
no one), so I don't know that you'll get an answer to your question.

Jim. 

-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
Ryan W
Sent: Friday, January 06, 2017 08:56 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] 64-but ONLY front end ?

Hi Jim,
  I realize 32 bit is still suggested, but I've hit a wall where it just
doesn't work for us. Between the 4 "primary" (aka most used) forms on the
front end it's quite easy to hit that Virtual Memory wall.  The Main Menu
(switchboard), the Jobs menu (logging in jobs from clients) which can lead
to the reporting menu (which not every one uses but our reporters do). Then
there's the Analytical Menu where all the number crunching is done and QA
overview is done are the ones people are in most of the time.  Then there
are tons of supporting forms with subforms for various tasks related to our
work.

Here are my DB stats:

?currentproject.AllForms.Count
409
?currentproject.AllReports.Count
205
?currentproject.AllModules.Count
33
?currentproject.AllMacros.Count
3
?CurrentDb.TableDefs.Count
626
?CurrentDB.QueryDefs.Count
216


A LOT of those tabledefs are back end (SQL Server). There aren't 409 actual
forms, obviously. Some of my most used forms may have 5-10 subforms on them
so it's easy to see how you could add up to 409 "forms" in the collection.



On Fri, Jan 6, 2017 at 5:52 AM, Jim Dettman <jimdettman at verizon.net> wrote:

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