[AccessD] 64-but ONLY front end ?

[John Colby]

You can tell what forms are open, there is a built-in collection for 
that.  Thus you can see what is already open and as a form opens have it 
refuse to open and shut back down with a warning (or something like 
that).  You could even do something semi-intelligent like discover how 
much each form uses and place it in a table such that you allow forms to 
open as long as the memory used stays below a threshold.

Ugly but possible.

On 1/17/2017 9:40 PM, Ryan Wehler wrote:
> I have one floating around. It's a marked improvement for sure but I'm not sure it will be enough.... I wish Access would release forms or tabs(form tabs not tab controls) that are in memory but not in focus to avoid stuff like this.
>
> If JIT controls isn't enough I'm not sure what else I can do other than try to tell people not to have too much open at once (like that would work)
>
>
> Sent from my iPad
>
>> On Jan 17, 2017, at 8:22 PM, John Colby <jwcolby at gmail.com> wrote:
>>
>> Have you managed to get a picture of the same 2013 x32 with JIT happening?
>>
>>> On 1/17/2017 3:35 PM, Ryan W wrote:
>>> A deeper look:
>>>
>>>
>>> Access 2013 32-bit on 64 bit OS:
>>> https://i.imgur.com/erUcFpo.png
>>>
>>> Access 2003 32-bit on 32 bit OS:
>>> https://i.imgur.com/1qCRQLm.png
>>>
>>>
>>> By the time I load my app up with JUST the switchboard open:
>>>
>>> Access 2013 32 bit:
>>> https://i.imgur.com/OkYxSsg.png
>>>
>>> Access 2003 32 bit:
>>> https://i.imgur.com/DeStcnt.png
>>>
>>>
>>> So I'm using 40% more memory just to run Access 2013!  Once I hit a "TOTAL"
>>> number of around 1.45GB I start getting out of resource errors.   When
>>> switching to 64 bit my memory wall becomes big enough (up to 8TB) that it's
>>> never ever a problem.
>>>
>>>
>>> Here we are with 5 of our most used and most commonly opened forms all
>>> opened up:
>>> https://i.imgur.com/RjPRpnd.png
>>>
>>> We are just barely skirting that limit here.  It would not take much (just
>>> a slightly larger data set on one of the forms) to stop the user in it's
>>> tracks.
>>>
>>> Those same forms open in Access 2003:
>>> https://i.imgur.com/ed296vH.png
>>>
>>>> On Tue, Jan 17, 2017 at 1:04 PM, Martin Reid <martinreid at gmail.com> wrote:
>>>>
>>>> He's been an amazing resource to
>>>> bounce ideas and questions off
>>>>
>>>> Has been for many years.
>>>>
>>>> Martin
>>>>
>>>> -----Original Message-----
>>>> From: "John Colby" <jwcolby at gmail.com>
>>>> Sent: ‎17/‎01/‎2017 18:01
>>>> To: "Access Developers discussion and problem solving" <
>>>> accessd at databaseadvisors.com>
>>>> Subject: Re: [AccessD] 64-but ONLY front end ?
>>>>
>>>> Assuming is mb?
>>>>
>>>>> On Jan 17, 2017 9:56 AM, "Ryan W" <wrwehler at gmail.com> wrote:
>>>>>
>>>>> For those following along:
>>>>>
>>>>>
>>>>> VMMap.exe (sysinternals) shows that Access 2003 sitting idle uses about
>>>> 75K
>>>>> of memory "total", Access 2013 (32 bit) is using 516K of memory "total"
>>>>> sitting idle. This is WITHOUT having my MDE/ACCDE loaded.
>>>>>
>>>>> Talk about bloat! It looks like a lot of this might be the 64 bit to 32
>>>> bit
>>>>> layer (SYSWOW)
>>>>>
>>>>> I'm still chasing down "JIT" forms (via Classes) with John Colby
>>>> providing
>>>>> assistance via email and telephone!  He's been an amazing resource to
>>>>> bounce ideas and questions off.
>>>>> --
>>>>> 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
>>>>
>> -- 
>> John W. Colby
>>
>> -- 
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com

-- 
John W. Colby