I've tried maxbuffersize registry setting. The only thing that works is to use /maxmem=1024 in boot.ini to restrict NT to 1gb Ram. NOT A SOLUTION!! Is there any jet3.0 or other patch out there or any other registry hacks out there?? Is there a way to limit avail ram on a per process basis not reqr reboot??

Urgent, Thanks
Terry

Hi Terry,
The maximum file size of a .mdb file is 1 Gb. If you attempt to exceed that, you may get problems. By the way, the size of any file on NT is limited to 2Gb (signed 32bit pointers). Therefore, you can do 2 things:
(1) Put your largest table in another .mdb file and link it into your first .mdb file (no need to change your vb code). That will, most likely solve your problem in the immediate future. To execute the link, you may for example use MsAccess.
(2) Put a number of your tables in another rdbms (and link them into your .mdb file), that does not put all its tables in one big file. If you don't want to spend too much on licensing for another rdbms, try, for example, mysql.
Note, however, that every rdbms on 32bit platforms will run into this problem, unless they have implemented special code to split a table over several files, and still be able to optimize their queries. Even then, every rdbms on a 32bit platform will start running pain-stakingly slowly from around 5Gb.

Hi Erik,
No Database will open - even small ones. We use ODBC to connect to Oracle. But even the VB biblio.mdb sample database won't open. The error occurs on the OpenDatabase method. I can only avoid the error by using /maxmem=1024 in boot.ini to restrict NT to 1gb Ram. But then why have 2gb ram if you can only use half of it??????

Are you sure that NT can use 2Gb of RAM?

Signed 32bits can address exactly 2Gb. If you substract the overhead, you will will end up with somewhat less than that. Therefore, I cannot believe that NT can address that much RAM. You must run into some kind of trouble, if you do anyway. When you're talking 32bits, you end up with limits that say, at the very best 4Gb (unsigned int), 2Gb (signed int).
Try using /maxmem=x, with x between 2048 and 1024. You will know the exact limit, in that way. You may be able to use more than 1024Mb, but I'm afraid that 2Gb are beyond the 32bit limitation.

By the way,
Even before anything else, why do you need one single machine with that much ram? There must be ways to partition your application, use clusters or otherwise split the cake...

Ha, if you're using Oracle over ODBC, go ODBCDirect to Oracle, by creating your DAO workspace like that (don't use the default, because it uses Jet); then VB will not load the Jet Engine. Somewhere at the beginning of your database conversation:

DBEngine.DefaultType = dbUseODBC
Set wrkODBC = CreateWorkspace("ODBCWorkspace", user, passwd)

You can do this, as long as you did not link the tables; if you did, you can't use this strategy, and you will have to re-write...

By the way, this assumes that the error is truly with Jet, and that everything else can handle 2Gb of ram. In theory, if every component was written properly, the limit should be 4Gb; but as you can see, that's only in an ideal world.

Hi Erik
All great idea's and the signed 32 bit limitation, I'm sure, is the underlying culprit. I did stairstep the /maxmem= parameter and 1024 (expressed in Meg) is the highest I could go to avoid the error.

ODBCDirect is not an option for me now because it is not introduced until Jet3.5 - I'm at Jet3.0

Somewhere in the OpenDatabase method, Jet is interested in either Total memory or Available memory. Some low level call is returning a binary value that when 'stuffed' into a 'signed' data type, appears as a negative value. OOPS 'out of memory'.

So...
I was hoping for a patch to either Jet3.0, or
one of the Kernel or User DLL's.

I've seen a similar situation with some Setup.exe programs. When they attempt to determine available drive space, they report negative bytes available. Luckily, you can chose to ignore and Setup will continue to install.

Hi Terry,

When they were writing for Jet3.0, I doubt there was even one NT server around with 2 Gb of ram.

I'm afraid that no one than the one who has the source code for Jet3.0 will be able to help you. This leaves you dangerously dependent on one company: Microsoft.

Microsoft's answer will undoubtedly be , if you ask them for help:
(a)Upgrade to 3.51, or 3.61 (even though I doubt the limitations have been addressed in these versions)
(b)Port your application to an SqlServer backend, using RDO or ADO. However, this means a complete rewrite, because ADO (and RDO) are totally different from, and incompatible with DAO.

Can you imagine that, if Jet3.0 were an open source program, you would be able to find someone on the internet who would fix the bug and send you the patch within days?

Or if you needed a consultant, that you would be able to get one to fly over for a few days to solve the problem?

What's even worse, Microsoft has degraded DAO to dead-end legacy software. They will stop supporting it any time soon. I really hate them for this, because the core of my skills (from which a buy my daily bread) are in DAO. Compounded with the fact that I hate wasting time learning a new object framework, I don't see anything useful for which I would need ADO.

I will be forced to port my skills to a new environment and set of tools, but I can tell you for sure, it will not be ADO or any other Microsoft product; as a matter of fact not any closed-source product controlled by a mentally sick company with hidden agendas.