Results 1 to 6 of 6
  1. #1
    Join Date
    Nov 2002
    Location
    Sydney, Australia
    Posts
    11

    Unanswered: Can not open any more databases (Err 3048 and 64509)

    I'm getting the above error in Access 97, first time in some 10 years of developing Access that I've seen it.

    Extensive searching leads me to think I'm somehow hitting the 2048 open databases limit in JET 3.51.

    Does anyone know of any way that I can check the number of currently open databases, so that I can find what's doing this?

    FWIW, the error occurs after opening a certain number of forms (8). Its not caused by setting variables to CurrentDb etc, as I religiously set all such refs to Nothing when exiting a function or sub.

    This is driving me nuts... so any suggestions would be really welcome.

    MTIA
    Max Hugen
    Hugen Enterprises Pty Ltd
    www.hugen.com.au
    Australia

  2. #2
    Join Date
    Aug 2002
    Location
    Northampton, England
    Posts
    266
    A couple of things spring to mind. If you have a lot of linked tables, this can cause this problem. Check your code and see if you are repeatedly opening recordsets - if yes, try to circumvent the need for those sets.

    David

  3. #3
    Join Date
    Feb 2004
    Location
    Chicago, IL
    Posts
    1,312
    My thought is that the error has little or nothing to do with the error message. I have gotten several messages from Access that don't exactly describe the true problem. I can't imagine that you are actually opening that many database objects at once. Have you tried the easy stuff? Repairing the database? Compacting the database? If you have, I might suggest importing all your objects into a blank database. That is what I used to do with a 97 database that suddenly started getting obsucre errors.

    Make sure you make a copy of the database first before you try repairing.

  4. #4
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    My thought is that the error has little or nothing to do with the error message.
    How true that is, especially with Access 97.

    In addition to DCKunkle's suggestions, pursue /Decompile command line switch. Also, it may have to do with quantity of code. I started getting "Out Of Memory" errors when opening a Form or Query on a rather larger project built in Acc97. My platform has 1GB of RAM and an 80 GB HD, so I dobt I was actually running low on memory. Turns out that Acc97 uses Jet's resources to store compiled code and as I was happily developing away, I was starving Jet. The fix was to decompile, then compile, then compact AND to sneak in the registry and up Jet's allotted memory (there's an MSDN article on this, I'd don't have the link handy )

    There's multiple threads in this forum on decompile, memory, mysterious errors, etc.

    hope this helps,
    tc

    ---------------------
    Try these:
    http://support.microsoft.com/default...;en-us;q103429
    http://support.microsoft.com/?kbid=161255
    http://support.microsoft.com/kb/191743/EN-US/
    http://support.microsoft.com/?id=172733

    I couldn't find the article I was refering to, but these are in the same pool of problems
    Last edited by tcace; 04-20-06 at 08:23.

  5. #5
    Join Date
    Nov 2002
    Location
    Sydney, Australia
    Posts
    11

    MS Response

    Thanks TC, actually I decomp/compile very regularly, plus compact etc, all of which helps to prevent Access getting it's knickers in a knot, esp in larger projects. Sometimes I find that Access corrupts objects, esp forms and reports, and then I rebuild the db - ie, create a new db and import all objects. This works 99% of the time.

    My US associate tackled MS about this, and I thought everyone might like to see their response:

    -- quote --
    Access will allow you to have 255 table ids open at the same time. For instance if you run a query based upon five tables you will have five table idsopen. If you open five forms based upon the same query you will have 25 table ids.

    There is not any way to get an accurate count of how tableIDs you have opened. Combo-boxes, list boxes, complex queries, code, numerous tables, system tables, etc. all contribute to the maximum number of TableIDs. For each of these objects, there may be more than one TableID created, so there is really no way of determining the number used. For instance if you run a query based upon five tables you will have five TableIDs open. If you open five forms based upon the same query you will have 25 table IDs. If the forms have combo boxes and list boxes, Dlookup statements, etc., you can see how you would eventually get to the error by exceeding the amount of TableIDs that can be accessed, but it would take a lot of objects which are tied to a lot of tables or queries to reproduce the error

    A TableID is a recordset pointer that the database engine uses, and is not exposed to the user. The Jet database engine may open multiple TableIDs during the execution of a single query; however, there is no accurate method to estimate the number of TableIDs that the Jet database engine will use for any given operation.

    If you have any code attempting to open multiple databases in the same workspace by way of a global variable, change the code to use procedure-level variables to initialize database variables when possible and eliminate the recursive variable declaration. When you split your database and link the tables in the background Jet will be creating at least 2 additional queries for each linked table to fetch the data. This approach would cause you to run out of available tableids more quickly than having all tables local. Hope this helps to clarify the behavior customer is seeing. Please let me know if you have any additional questions.
    -- end quote --


    Cheers, Max
    Max Hugen
    Hugen Enterprises Pty Ltd
    www.hugen.com.au
    Australia

  6. #6
    Join Date
    Jul 2005
    Posts
    50
    I really feel when your projects get this convoluted, you guys are using the wrong tool to do the job. (Microsoft Access is not the muscle man we sometimes try to make it to be.)

    You need to go to a more robust solution. My next step would be SQL Server or equivalent as a backend and a client or web interface.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •