[AccessD] 64-but ONLY front end ?

[Ryan Wehler]

Yeah I know. These controls were here before navigation forms were. 

To migrate everything might be painful.... I've thought about it more than once. 

Sent from my iPhone

> On Jan 8, 2017, at 12:04 PM, Charlotte Foust <charlotte.foust at gmail.com> wrote:
> 
> Take a hard look at navigation forms.  This is precisely what they do,
> allow you to jump back and forth, loading and unloading the subforms as you
> go.  I use them extensively, and while they require more attention and do
> not sink subform events, they vastly improve the speed of the application.
> 
> Charlotte Foust
> 916-206-4336
> 
>> On Jan 6, 2017 5:19 AM, "Ryan Wehler" <wrwehler at gmail.com> wrote:
>> 
>> We don't necessarily need a bazillion forms open at once. We are usually
>> working in one at a time but the ability to jump back and forth with tabs
>> is enticing to me and my users. Unfortunately once a few are open and
>> anything complex is attempted I get an out of resources message
>> 
>> If I monitor virtual memory via access I can see with. Irving but my base
>> form open we are trending on 800MB MEMORY used. Open a few forms and we are
>> at 1.2 GB. By the time we hit 1.4-1.5GB is about when the out of resource
>> messages come piling in.
>> 
>> 
>> Carlotte,
>> 
>> Rather than just blast my design (which had worked just fine up until
>> moving to access 2013) why don't you tell me some "good design principles"
>> you have and I can tell you I probably already follow 90% or more of them.
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 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
>> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com