Hi Select,

Sorry for being a pain, but example one in your test does have dbGrid objects instead of the dbcjGrid one's?

Quote Originally Posted by Select View Post
1. When we run without cjDBGrid.vw the memory used on startup is
a. 24,376kb (1 secs),
b. 28,176 (3 secs)

2. When we run with cjDBGrid.vw the memory used on startup is
a. 54,328kb (16 secs),
b. 56,624kb (17 MINUTES)
In example 2 here you picked the 17 minutes because the applications are unusable before that time? If so that would suggest some serious swapping due to memory constraints, but without a VM configuration (hint:vmware.log) it's guess work.

Of course I don't know your load, but I'm not shocked by applications using 60MB of memory, do add the VM Size column to the task manager as I think they are using a lot more memory for the problem you are describing.

re. Drivers, I meant the direct database drivers, either mertech or DAW. There are parameters you can set on how much memory is being used per record fetch.

re. codejock grids I'm not 100% sure that setting auto_fill_state to false is enough to have them not load data. I think they still try to read in a few pages, like pbAutoSeed in cDbCJGridPromptList does. Setting Auto_Fill_State to false at the Datadictionary object might help as well.

re. many variables.. VDF runtime differences, for example since VDF17.0 datadictionaries behave different on extended columns (edit columns) and if you have a big column it would use more data by default. So both test applications should be the same VDF version. See also: pbBypassDDFieldBuffer

Anyways, way past midnight here, time to call it a day. If you don't want to attach the vmware.log file, then you can pm me for my email address (or look it up at http://www.antwise.com ) But as you have reproduced the problem outside of vmware (windows 2008 R2 non-VM?) I doubt your problem is VMware related.

--
Wil