Multiple access applications - potential class conflict / memory bleed

[1DMF]

Hi,

We have multiple access applications, some of which use the same classes - not from a shared resource.

One application seems to grind to a halt if the user has another one open at the same time.

Is it possible there is conflict between applications or should they both run seperate within their own memory allocation?

Can similar instances of classes in separate applications cause conflicts with each other?

Your advice is appreciated.

1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[kjv1611]

This is just a wild guess on my part, but if they are using classes, and those classes are essentially the same or similar, and point to the same .dll file(s) within the Windows system folders, then perhaps there is some resource sharing issues happening between multiple applications.

Also, are you 100% sure they are not sharing any of the same linked tables perhaps? If they did both try to hit the same linked table at the same time, I'd imagine one could be forced to wait on the other to complete its processes... based on how the record locking is setup..

"But thanks be to God, which giveth us the victory through our Lord Jesus Christ." 1 Corinthians 15:57

 

[1DMF]

Hi Kjv1611,

I'm not sure if they would point to the same DLL, it contains two recordset objects, both DAO , but having multiple recordsets isn't normally a problem is it?

They are not using the sames linked table, as the app which is locking up uses a stored procedure to obtain a recordset (which I understood is always readonly), once obtained all filtering is performed against the memory resident recordset.

I'm assuming once a recordset is returtned from an SP and attached to a form's recordsource, there is no longer a link between the application and the SQL DB, is there?

Your insight is appreciated.

1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[kjv1611]

For each form to show the data, they have to store the data in memory - RAM. So, another possibility, I'd imagine, is that Access is storing so much for one form, that once you open the 2nd form, it's causing it to run out of resources. I wonder, if as in this case, there is a limit to how much can be taken by just Access in general. So, what does Access do when Windows says, "Nope, no more RAM for you!"

This is all just thinking about possibilities. I can't tell you a definite cut and dry answer, unfortunately.

Another reason I think about that is I've seen desktops here at work, where on one system(a Core 2 Duo - or recently Core i5), a database would open fine, but on another (say with a Celeron processor) the same application would be rather slow. Data connections, etc were same, but the slower system couldn't handle the load.

So, in your case, perhaps one database by itself is fine, but when you load 2 at same time, they are simply fighting for resources, and in this case, Windows is giving priority to "first come, first serve".

"But thanks be to God, which giveth us the victory through our Lord Jesus Christ." 1 Corinthians 15:57

 

[1DMF]

So what does windows do with the 4GB of ram this code 2 duo machine has?

Does it waste it reserving for a porgram thqat might get opened?

If you only ever opened 1 program at a time, is most of your memory wasted and the one program you have open starved of resources?

Seems a bit odd if that is the case?

Another thing is that it was working fine before, we have had a new server put it and IT company changed everything I've spent years setting up and getting to work perfectly, and we have had problems ever since.

dunno coincedence perhaps, but it doesn't make it any easier tracking down why things have stopped working how they used to!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

MIME::Lite TLS Email Encryption - Perl v0.02 beta

 

[kjv1611]

Is there any way to test this away from the updated machine? Or is there a way the machine could be checked for issues in RAM... or either issues with data corruption? It does sound fishy.

"But thanks be to God, which giveth us the victory through our Lord Jesus Christ." 1 Corinthians 15:57