Ошибка 3183 access

I inherited this Frankenstein application at work that utilizes an Access 2007 DB frontend with linked tables to an Oracle 10g DB.

Users have started reporting that a lot of the queries are failing with an error 3183 out of temporary space. These same queries have run fine a few weeks back.

I verified that Access is creating a 2GB temp file which is the maximum amount allowed in the system temp directory.

Even if I run the query using parameters that would not return data, I still get the error. Doing a SQL trace shows that some of the queries are trying to run a queryset that would return about 14 million rows. I know some of the queries are poorly designed, but that is not an easy thing to change.

I had the Oracle DBA double the temp space, but still didn’t fix the issue.

I guess my question is does an Access DB use the temp space available on the linked ODBC database first then use the temp file if no Oracle temp tablespace is available? Any ideas why this would start happening or is it just that the amount of the data in the Oracle database has exceeded the ability of Access? The way the application was created had been working up until a few weeks back or so.

Understand redesigning this app is not an easy option. I am more looking for an idea as to why this would have worked before and started happening recently.

This is the Access RAW SQL.. Understand I didn’t write this.. The Oracle tables at least didn’t have space and ampersands. :)

    SELECT DISTINCT [Event: Overhaul & Repair].BASE_PART_NUMBER,
  [Event: Overhaul & Repair].PERIOD,
  [Event: Overhaul & Repair].RECEIVED_BY_FACILITY_DATE,
  [Event: Overhaul & Repair].PART_NUMBER,
  [Event: Overhaul & Repair].CONFIGURATION_RECEIVED,
  [Event: Overhaul & Repair].PART_SERIAL_NBR,
  [Findings: Feature Findings Detail].SUBASSEMBLY_NAME,
  [Findings: Feature Findings Detail].COMPONENT_NAME,
  [Findings: Feature Findings Detail].FEATURE_NAME,
  [Findings: Feature Findings Detail].FAILURE_DESCRIPTION,
  [Findings: Feature Findings Detail].PRIMARY_FAILURE_IND,
  [Event: Overhaul & Repair].REMOVAL_JUSTIFIED_FLAG_ON_OR,
  [Event: Overhaul & Repair].CUSTOMER_NAME_SUBMITTING,
  [Findings: Feature Findings Detail].AIRCRAFT_TYPE,
  [Event: Overhaul & Repair].AIRCRAFT_REG_NUMBER,
  [Event: Overhaul & Repair Text].NOTE_TEXT,
  [Event: Overhaul & Repair].TIME_SINCE_NEW_ON_OR,
  [Event: Overhaul & Repair].TIME_SINCE_INSTALL,
  [Event: Overhaul & Repair].TIME_SINCE_OVERHAUL_ON_OR,
  [Event: Overhaul & Repair].FACILITY_NAME,
  [Event: Overhaul & Repair].EVENT_SEQNO
FROM ([Event: Overhaul & REPAIR]
LEFT JOIN [Event: Overhaul & REPAIR Text]
ON [Event: Overhaul & REPAIR].EVENT_SEQNO=[Event: Overhaul & REPAIR Text].EVENT_SEQNO)
LEFT JOIN [Findings: Feature Findings Detail]
ON [Event: Overhaul & REPAIR].EVENT_SEQNO=[Findings: Feature Findings Detail].EVENT_SEQUENCE_NUMBER
WHERE ((([Event: Overhaul & Repair].BASE_PART_NUMBER)=[PART NUMBER])
AND (([Event: Overhaul & Repair].PERIOD) BETWEEN [START DATE YYYYMM] AND [END DATE YYYYMM])
AND (([Findings: Feature Findings Detail].PRIMARY_FAILURE_IND)="PF"
OR ([Findings: Feature Findings Detail].PRIMARY_FAILURE_IND) IS NULL)
AND (([Event: Overhaul & Repair Text].NOTE_TEXT)="R"));


Summary:

You can encounter the error 3183 — The query cannot be completed in MS Access when the application fails to read the query you are trying to execute. This blog summarizes the causes behind this error and mentions some effective methods to fix it. It also mentions an advanced Access recovery tool you can use to repair the database if the query fails to run due to database corruption.

Free Download for Windows

Contents

  • Why Access Error “The Query Cannot Be Completed” Occurs?
  • Method 1: Check and Adjust Access Macro Settings
  • Method 2: Create a New Database
  • Method 3: Optimize the Database Size
  • To Conclude

VBA queries are used to interact with the Access database. These queries help to perform various operations, such as selecting, retrieving, manipulating, or inserting data in Access database files. While using VBA queries, sometimes, you can get errors. The error 3183 “Query cannot be completed” is one of the VBA errors. When this error message pops up on the screen, your application may get stuck while executing the VBA projects, leading to work interruption. Below, we will be mentioning some easy and effective methods to fix this error. But before troubleshooting this error, let us understand the causes behind it.

Why Access Error “The Query Cannot Be Completed” Occurs?

The error 3183 – “Query cannot be completed” can occur while using the VBA code in Access. It can happen when importing or exporting a database file to or from other databases, like SQL databases. It can also occur if the size of the query result is larger than the maximum size of a database (2 GB) file or there is not enough temporary storage space on your system’s disk to store the query result. The error can also appear when using lookup columns in Access to display values from a related table. It usually occurs when there are many tables with several relationships in a database file.

Below are some other causes of the error:

  • When queries or macros get damaged.
  • Incorrect Access macro settings.
  • If you are using complex queries that involve multiple tables, joins, etc.
  • You do not have necessary permissions to access the table that your queries are pointing to.
  • Missing or incorrect field names or other syntax errors in the SQL queries.
  • Relationships are not defined correctly in the tables or queries.
  • Incompatible SQL Server data types in the code.

Methods to Resolve the “The Query cannot be completed” Error in MS Access

Error 3183 can occur if there are inconsistencies between the Access data types and SQL data types in the queries. It usually occurs when your database contains queries that require converting data from one type to another. So, ensure you are using the Access data types that are compatible with the SQL data types. You can compare Access and SQL Server data types to troubleshoot the data type issue in the query. If the error persists, follow the below methods.

Method 1: Check and Adjust Access Macro Settings

The error 3183 – “The Query cannot be completed” in Access can occur due to disabled Macro settings. You can try changing the Macro settings to troubleshoot the error. Here are the steps:

  • Open the desired database file.
  • Go to File > Options.
  • In Access Options, click Trust Center and then click Trust Center Settings.

Clicking Trust Center Settings from Trust Center

  • In the Trust Center window, select Macro Settings and then check the options under Macro Settings.

Enabling all macros from Macro Settings

  • Select the “Enable all macros” option and then click OK.

Method 2: Create a New Database

Creating a new Access database and importing all the tables and relationships from the original database into it can help fix the error 3183. This method is helpful if there are inconsistencies in the database. Here are the steps to do so:

  • In Microsoft Access, go to File, click the New option, and click on Blank Database.

Adding New Blank desktop database

  • Give a name to the database and save it.
  • Now in the new database, click the External Data option and click Access.

Clicking Access from External Data

  • Go to the location of the desired database and then select it.
  • Select the “Import tables, queries, forms, reports, macros, and modules into the current database” option. Click OK.

Importing from source and destination of the data

  • In the Import Objects window, select the individual objects (queries, macros, etc.) you want to import or click the Select All option. Then, click OK.

Importing objects from tables

After you have imported all the objects, recreate all the queries. Now check whether the issue is fixed. If not, then follow the next method.

Method 3: Optimize the Database Size

MS Access supports database files of maximum 2 GB size. The database file exceeding the 2 GB size limit may result in “The query cannot be completed. Either the size of the query result is larger than the maximum size of a database (2 GB), or there is not enough temporary storage space on the disk to store the query result” error. You can manage the oversized database file to resolve the issue. Also, check and make sure the drive in which your database resides has sufficient memory.

Method 4: Check the Database Permissions

Sometimes, the error 3183 can also occur if you are trying to create queries in the database in which you do not have sufficient permissions. You can check and change the permissions of the database to troubleshoot this issue.

Method 5: Check the Queries in the VBA Code

You can also get the Access error 3183 – “Query cannot be completed” if there is an issue with the VBA code you are trying to execute. Even a minor mistake in the SQL expressions or statements can create an issue. You can check the syntax of the queries and query references fields and try fix them (if there is any issue).

Method 6: Compact and Repair your Database

The error “Query cannot be completed” can occur if the size of the database is too large or there is corruption in the database. In such a case, you can use the Microsoft built-in utility – Compact and Repair to compact and repair the database. To use this utility, follow the below steps:

  • First, make sure the affected database file is not opened.
  • Then, open your Access application. On the Templates page, click Blank Database.
  • Click File and then select Close.
  • Click Database Tools > Compact and Repair Database.

Selecting Compact and Repair Database Tools from Database Tools

  • In the “Database to Compact from” window, scroll down to choose the database that you want to compact and repair. Click Compact.

Selecting Database from Local Disk drive and selecting compact

The compacted and repaired database will be saved at the exact location where the original database file is saved.

The Compact and Repair tool may fail if the database file is severely corrupted. In such a situation, you can use Access repair tools, such as Stellar Repair for Access. The tool is specially designed to repair severely corrupted ACCDB/MDB files. The tool extracts records, tables, modules, queries, macros, and other components from the damaged database file and save them in a new database file, with complete precision and integrity. You can download the software’s demo version to preview the recoverable data in the corrupted database file. It is compatible with all Windows editions, including the latest Windows 11.

To Conclude

The error 3183 – “Query cannot be completed” in Access can occur due to incorrect or corrupted queries, large-sized databases, and more. You can try the methods mentioned above to resolve the error. If the database is corrupt, you can repair it using Stellar Repair for Access in just a few clicks. It is an advanced tool with a user-friendly UI that helps you recover all the data from the corrupted Access database file without changing the original formatting.

About The Author

Monika Dadool

Monika Dadool is a Technical content writer at Stellar who writes about QuickBooks, Sage50, MySQL Database, Active Directory, e-mail recovery, Microsoft365, Pattern Recognition, and Machine learning. She loves researching, exploring new technology, and Developing engaging technical blogs that help organizations or Database Administrators fix multiple issues. When she isn’t creating content, she is busy on social media platforms, watching web series, reading books, and searching for food recipes.

Search code, repositories, users, issues, pull requests…

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Icon Ex Номер ошибки: Ошибка 3183
Название ошибки: The query cannot be completed
Описание ошибки: The query cannot be completed. Either the size of the query result is larger than the maximum size of a database (2 GB), or there is not enough temporary storage space on the disk to store the query result.
Разработчик: Microsoft Corporation
Программное обеспечение: Microsoft Access
Относится к: Windows XP, Vista, 7, 8, 10, 11

Основы «The query cannot be completed»

«The query cannot be completed» часто называется ошибкой во время выполнения (ошибка). Разработчики программного обеспечения, такие как Microsoft Corporation, обычно принимают Microsoft Access через несколько уровней отладки, чтобы сорвать эти ошибки перед выпуском для общественности. К сожалению, некоторые критические проблемы, такие как ошибка 3183, часто могут быть упущены из виду.

«The query cannot be completed. Either the size of the query result is larger than the maximum size of a database (2 GB), or there is not enough temporary storage space on the disk to store the query result.» может возникнуть у пользователей Microsoft Access даже при нормальном использовании приложения. Когда появится ошибка, пользователи компьютеров смогут уведомить разработчика о наличии ошибки 3183 через отчеты об ошибках. Затем Microsoft Corporation будет иметь знания, чтобы исследовать, как и где устранить проблему. Чтобы исправить любые документированные ошибки (например, ошибку 3183) в системе, разработчик может использовать комплект обновления Microsoft Access.

Когда происходит ошибка 3183?

«The query cannot be completed» чаще всего может возникать при загрузке Microsoft Access. Рассмотрим распространенные причины ошибок ошибки 3183 во время выполнения:

Ошибка 3183 Crash — Ошибка 3183 может привести к полному замораживанию программы, что не позволяет вам что-либо делать. Эти ошибки обычно возникают, когда входы Microsoft Access не могут быть правильно обработаны, или они смущены тем, что должно быть выведено.

Утечка памяти «The query cannot be completed» — при утечке памяти Microsoft Access это может привести к медленной работе устройства из-за нехватки системных ресурсов. Повреждение памяти и другие потенциальные ошибки в коде могут произойти, когда память обрабатывается неправильно.

Ошибка 3183 Logic Error — Вы можете столкнуться с логической ошибкой, когда программа дает неправильные результаты, даже если пользователь указывает правильное значение. Обычные причины этой проблемы связаны с ошибками в обработке данных.

Повреждение, отсутствие или удаление файлов The query cannot be completed может привести к ошибкам Microsoft Access. Основной способ решить эти проблемы вручную — заменить файл Microsoft Corporation новой копией. Запуск сканирования реестра после замены файла, из-за которого возникает проблема, позволит очистить все недействительные файлы The query cannot be completed, расширения файлов или другие ссылки на файлы, которые могли быть повреждены в результате заражения вредоносным ПО.

Распространенные проблемы The query cannot be completed

Наиболее распространенные ошибки The query cannot be completed, которые могут возникнуть на компьютере под управлением Windows, перечислены ниже:

  • «Ошибка программы The query cannot be completed. «
  • «The query cannot be completed не является программой Win32. «
  • «Извините за неудобства — The query cannot be completed имеет проблему. «
  • «The query cannot be completed не может быть найден. «
  • «Отсутствует файл The query cannot be completed.»
  • «Ошибка запуска программы: The query cannot be completed.»
  • «The query cannot be completed не работает. «
  • «Отказ The query cannot be completed.»
  • «The query cannot be completed: путь приложения является ошибкой. «

Эти сообщения об ошибках Microsoft Corporation могут появляться во время установки программы, в то время как программа, связанная с The query cannot be completed (например, Microsoft Access) работает, во время запуска или завершения работы Windows, или даже во время установки операционной системы Windows. Запись ошибок The query cannot be completed внутри Microsoft Access имеет решающее значение для обнаружения неисправностей электронной Windows и ретрансляции обратно в Microsoft Corporation для параметров ремонта.

Причины проблем The query cannot be completed

Проблемы The query cannot be completed могут быть отнесены к поврежденным или отсутствующим файлам, содержащим ошибки записям реестра, связанным с The query cannot be completed, или к вирусам / вредоносному ПО.

Особенно ошибки The query cannot be completed проистекают из:

  • Недопустимые разделы реестра The query cannot be completed/повреждены.
  • Загрязненный вирусом и поврежденный The query cannot be completed.
  • The query cannot be completed злонамеренно удален (или ошибочно) другим изгоем или действительной программой.
  • Другое программное обеспечение, конфликтующее с Microsoft Access, The query cannot be completed или общими ссылками.
  • Microsoft Access (The query cannot be completed) поврежден во время загрузки или установки.

Продукт Solvusoft

Загрузка
WinThruster 2023 — Проверьте свой компьютер на наличие ошибок.

Совместима с Windows 2000, XP, Vista, 7, 8, 10 и 11

Установить необязательные продукты — WinThruster (Solvusoft) | Лицензия | Политика защиты личных сведений | Условия | Удаление

  • #1

Hi,

I’m developing an Access application that pulls schedule data from an oracle database and processes the data, filling in gaps in the schedules.

Ultimately the application will process two years worth of schedule data for tens of thousands of employees where some employees can have multiple shifts in a day with a schedule that updates weekly, while others have a fixed schedule that has been in place for years.

The end result will be a daily schedule row per employee showing number of hours worked that day to be used in various reports.

To get around the 2Gb Access database limit, I have developed a set of backend databases with a master front end that moves data from pre-processing to processing to processed.

I’m getting the following error when running the application:

Run-time error ‘3183’:
The query cannot be completed. Either the size of the query result is larger than the maximum size of a database (2 GB), or there is not enough temporary storage space on the disk to store the query result.

I had this error initially and further split out backend tables into addtional separate databases, but am still getting the error.

I’ve been Googling this and other forums looking for a solution. I’ve tried the suggestions in this post:
http://www.access-programmers.co.uk/forums/showthread.php?t=96471&highlight=3183

I can’t see any files that would be relevant in either directory:
C:\Windows\Temp\*.*
C:\documents and settings\username\local settings\Temp\*.*

I’m developing in MS Access 2010 on a client laptop running Windows 7 service pack 1, several hundred Gb free disk space, 4Gb RAM, 64 bit OS, i5-4300U CPU @ 1.90GHz

The front end database is only 2Mb. Currently the largest backend database is 500Mb. Paging file size is 3783Mb

The most recent time I received the error, none of the database sizes were approaching 2Gb. When I clicked debug, the code broke on:
Set rstTOP = cdb.OpenRecordset(«qryProcessTOP», dbOpenDynaset)
I tried running the select query (while in debug mode) and got the same error. I killed the code. Tried running the query again and it was returning fifty rows on one column only. No table joins.

This implies to me that this is a memory issue, or Access Temp file issue.

Is there a way to find out what is taking up the space in the Access temp file (and even, where the Access temp file is/what it’s called?)

Or would anyone have any other suggestions?

Thanks

Mark

:banghead:

  • #2

Dunno if this is relevant in your case but I’ve seen something like this when running UNION queries without ALL. Adding ALL cured the problem.

  • #3

Hi Spikepl,

Thanks for the reply. The query I’m trying to execute when I get the error is a simple select query, but there are union queries in other parts of the process. I’ll try modifying them.

gemma-the-husky


  • #4

I presume it’s the first bit of this. The query will be a temporary object of over 2Gb.

Run-time error ‘3183’:
The query cannot be completed. Either the size of the query result is larger than the maximum size of a database (2 GB), or there is not enough temporary storage space on the disk to store the query result.

Why would you need 2 years of old data to get a single days/weeks results?

Can you not pre-filter the history table at an earlier stage, with a query. Put the extract in a temp table, if you have to.

  • #5

Your little SELECT couldn’t possibly casue all that damage, so something must have accumulated …

  • #6

Hi Dave,

The client requirement is for a report providing schedule hours for each employee over two years. Some employees have a schedule for a week which once set never changes. (some going back a decade or more) That employee may have a maximum of seven rows of data. Other employees have constantly changing schedules with multiple shifts per day. Those employees can have hundreds of rows of data for a given month.

If it were just a case of returning data I could use a pass thru query, but I haven’t thought of a way to return schedule data for a current year when there is only one set of schedule data relating to a decade ago.

By bringing the schedule into Access I’ve been able to loop through a month of days, converting the historic schedule into a current one.

It is slow though, any suggestions for improvements would be helpful ;)

  • #7

Dave,

Getting off topic now, but I’ve been refactoring as I’ve developed and maybe it would be possible to make large parts of the process redundant.

One possibility would be to use some form of cartesian join. Return the schedule start date, day of schedule and the date of the next schedule that replaces the schedule being returned. (Lots of schedules overlap which has meant I need to remove out of date schedules)

If the above data was joined to a query that returned one row for every day, where (schedule start date > = day) and (date of the next schedule > day)
that could work…

Will have to try that. Could save a lot of processing time.

  • #8

Hi SpikePL,

Yeah, that’s what I’m wondering. I’ve been careful to close all open recordsets as I finished looping through employees/months, but is it possible that closing them and setting them to nothing does not free up memory — so since I’m processing large numbers of records, the space used in memory / temp space (however Access is storing it) is being eroded?

The_Doc_Man


  • #9

I might respectfully disagree with Gemma on which part of that error message is the relevant part. I think it could be either. I could see a case — and can’t tell from anything I see in the thread — where the relevant part is «there is not enough temporary storage space on the disk to store the query result.» (My logic on that one is at the bottom of my response.) However, I can also see Gemma’s thought here and absolutely can agree that it COULD be that the intermediate result is bigger than 2 Gb.

Depending on how you wrote the query, it is possible that you are getting caught on internal temporary query lists. In order to do a select query (at least as I understand the flow of Access), you first build a list of qualifying records. If it happens that you have nested queries, the intermediates can get quite ugly. For example, let’s say you are doing a 3-way join. Often, you cannot do a straight-up 3-way but instead must choose to do a 2-way join and then form the final join with the third table and the two-way join query as your two components.

If that happens, then the 2-way join has its own list (that must be built first) and the 3-way join has another list. Depending on how often you use queries as record sources in your main query (due to those pesky JOIN rules), you may have some really huge lists. The solution is going to be to carefully select the intermediate query combinations so that you can apply WHERE clauses to the intermediate query — thus hopefully reducing the size of the intermediate list. If you have the case that I just described, one symptom you might find is that it is going to be necessary to compact and repair your database more often.

There is another question that I cannot answer because here, I’m a bit out of my depth. Perhaps another forum member can answer for you. (And if so, we will BOTH learn something.) When you open database A and then use queries to open databases B, C, D — or even if you just link the tables to A — and you execute a query where the extra databases are involved by linkage rather than by queries with explicit «IN file» clauses, where do the temporary tables go that I described earlier?

That is, if I have to build that intermediate list, does it always go into database A or can it ever spill over into one of the others? (I believe the answer is «NO» but can’t prove it.) If the intermediate files all go to A then eventually you will fill up A will those intermediates. That is why I suggested trimming the intermediates with WHERE clauses to keep that list smaller.

It might even be necessary to have A be like a front-end file with NO local data of its own so that you maximize the free address space for your intermediate tables, but I can’t guarantee that it would be enough unless you can also do things to reduce the preliminary intermediate list size.

The case where the memory on your system becomes relevant (my contention that differs from Gemma’s viewpoint) is that your page file size is 3.7 Gb and you are looking at multiple 2 GB databases. When you open the database in a way that would cause it to be scanned for a query, you run into the COMMIT/CHARGE issue. Even though that chunk of the database is in a file, I think you have to commit paging space for it because Access has to bring it into memory to work on it. Based on your discussion of your structure, each such database is 2 Gb of data space.

If you have a 2 GB main database and 2 more auxiliary DBs of 2 GB each, that’s 6 GB. Add the space required for the Access program itself (which is external to the DB), add in the Windows permanent stuff, and then add the virtual DATA spaces implied by opening large DBs and suddenly you realize that you have just topped out your page file by a bunch.

You can test whether I am right by running Task Manager in a small window where you can seen the stats for physical memory, kernel memory, and system memory. The Commit number under system memory is going to be the one to watch. Open your database as other than full-screen so that you can watch the stats on Task Manager. If system memory «COMMIT» tops out at 3.7 Gb then your problem is SYSTEM virtual data space, not necessarily ACCESS virtual space.

You can try to expand your page file though you might have to defrag your disk in order to get enough contiguous space. (And there is no guarantee that it is even possible depending on the size and «clutter factor» on that disk.)

I would also point out that if you have a really complex data set that comes from a flat-file (EXCEL, e.g.) origin, you might gain a LOT of ground by looking at whether your datasets can be normalized better to reduce their size in some way. This is a case where a little goes a long way because of the large number of records that would be affected by normalization.

  • #10

Hi Doc Man,

That is a useful reply, thank you.

While none of the backend databases are approaching 2Gb in size while running the process, together they are greater than 1Gb just with the data. I would like to know and be able to test whether the query result sets are increasing the front end or back end temp file size.

The paging file limit is certainly a possibility. I will check that out as well,

Mark

The_Doc_Man


  • #11

To test the front-end file, be sure you have the task manager «processes» list up and see if the amount of memory associated with the MSACCESS task (under memory usage) is the one that is growing or the System Memory COMMIT space is growing. It is convenient that both task memory and system memory are visible on the same tab of the Task Manager. The MSACCESS task is the correct name of the .EXE fil and is what you will see in the processes list.

As to the total size of the static databases, that is immaterial to a very large degree. What matters is that the compacted databases are the SMALLEST amount of memory that must be committed when you open the file. I can be wrong on this but I don’t think I am… Windows will not bring something into memory until it knows ahead of time (by committing page file space) that it could do a page-in or full-blown in-swap. I also believe that if you start growing one of those intermediate tables, your performance will radically suck for the duration of the time that the page-file space is re-allocated. And if it should happen that you have to shuffle the page file to gain contiguous space, you will be looking at one of the great wonders of the world — the one that says «I wonder if I’ll ever hear from this system again.»

gemma-the-husky


  • #12

I have no issue with the DocMan suggesting that it might be a temporary storage problem.

As an alternative, can you run this for a single employee, rather than all employees?

In which case maybe you can do this

1. have a select query of the employees in which you are interested.
2. iterate this record set.
3. on each iteration write the output results to an output table
4. use the output table for final reporting.

This would hopefully avoid the need to produce mega-large record sets.
You also have an interruptible process, so you can add a useful progress monitor to step 2.

  • #13

SpikePL,
Turns out I only had two union queries in the whole application. One
wasn’t relevant to the process causing the error as it runs at an
earlier stage. Changed the other to UNION ALL.
Not sure what effect this will have…
My understanding of UNION ALL is that it returns ALL records as per:
https://msdn.microsoft.com/en-us/library/bb208962(v=office.12).aspx
«By default, no duplicate records are returned when you use a UNION
operation; however, you can include the ALL predicate to ensure that
all records are returned. This also makes the query run faster.»
While it is helpful to have the query run faster, will returning
duplicates possibly use less virtual/temp memory than excluding them?

Doc Man, I ran into another problem trying to reset the data to
retest. I’ve fixed it now, but am wondering if the cause of the
problem was related/causing the main issue of out of memory.
In order to cut down the volume of data I’ve taken several passes at
cleansing the data before it is processed. Removing all irrelevant
schedules and removing duplicates/cross over schedules. (The system
has some employees with a schedule that runs for a year, but is
updated weekly, therefore there are a large number of out of date
records.)

My query to remove these duplicates joined on two sub queries and was
taking a couple of minutes to run each loop (and I was looping
through batches of 50/100 employees trying to find the most efficient
way to process them). Then, when retrying to test, the query
generated an error, the only difference being the unneeded records
had already been deleted.

All that is probably TMI without enough detail…

Anyway, I’ve refactored the delete crossover schedules query/process and that now runs for all employees/schedules at the start of the process and is much faster.

I’ve recombined the three main backend databases into one to try and avoid three backends being opened at once.

Retesting, I got three times as far into the process before getting the same error as originally. This time the error was on line:

Code:

DoCmd.RunSQL "DELETE * FROM PreProcess WHERE EMPLOYEEID <=" & Chr(34) & strEmpID & Chr(34)

I tried modifying the line while in debug to

Code:

cdb.Execute "DELETE * FROM PreProcess WHERE EMPLOYEEID <=" & Chr(34) & strEmpID & Chr(34), dbFailOnError

but this threw up a slightly different error: Run-time error ‘3035’
System resource exceeded

Searching this I found several forums recommending upping the page locks value, so have added this:

Code:

 DAO.DBEngine.SetOption dbMaxLocksPerFile, 1000000

With reference to the attachment: KillChrome.png, checking the Task Manager while running the process and looking at file sizes, I couldn’t see any difference in System Commit while the process was running other than when I shut down Chrome which resulted in the dramatic drop in the history graph.

The Free Physical memory did approach zero at times but always had similar values in cached and Available. Commit never went above 4000.

The file sizes of the backend database and front end did together approach 2Gb and I’ve added a check that where backend DB size goes above 1.3 Gb it will be compacted/repaired.

Am going to give the process another run this evening and will feed back.

  • KillChrome.png

    KillChrome.png

    74.8 KB · Views: 441

  • #14

Hi Dave,
That step suggestion is very close to the process I’m following. I’m indeed only looking at one employee at a time, writing their schedules to a separate table and closing it. That final table/Db is the only one that is not getting bloated.

gemma-the-husky


  • #15

one other thing is maybe somewhere within your queries you have a Cartesian/cross-product join in a query, where you haven’t joined keys correctly.

if you have 1000 rows in 2 tables, and don’t join them correctly, you may get a cross product of 1million rows. This could well exceed system resources, and may get filtered out by subsequent actions, so you don’t realise it is happening.

can you time the queries, and see if one particular step is taking a long while to complete. That might be a good point to investigate.

The_Doc_Man


  • #16

The «Out of resources» item is a bit awkward to fix because you have to modify some things in the system definition files. In simplest terms, a Windows Resource is a read-only item used by programs. There is a table of slots for pointing to resources. It has a finite capacity. The resources themselves can be in individual files, perhaps even embedded in those files, but they are registered in the resource table. If you fill up that table, you are out of resource slots. I’m not a fan of the error message Microsoft used, because you can never actually run out of resources until all your disks are full. But you can run out of the slots in the table that registers the resources used by a given program.

My thinking is that if you collapsed three files into one and got three times farther in the process, you are running out of Access address space, particularly if the COMMIT didn’t change much but the individual task memory DID change to approach 2 Gb.

Dave’s comments regarding Cartesian JOINs is also spot-on as a trouble source. The other question I have is whether your WHERE clause involves a primary key or not. The amount of space needed to store an intermediate query list is less if you are using the PK as opposed to a non-key field because you can store data from the index in the former case. That index is inherently smaller than the records for the non-key case.

  • #17

Update as of Wednesday AM. I’ve further refactored queries being used in the process to minimize use of sub queries and replaced the ultimate code used to write the schedule (using recordset.add / .update) with a db.execute sql where the sql is a dynamic append/insert values string.

I set this off yesterday evening. I’m getting a different error now… Run-time error 3073 Operation must use an updateable query. I think this is because the code is now running fast enough that the table is not released before the next append runs. I can handle that by error trapping or checking for presence of a lock file (or maybe by bringing that final table into the main backend database as well.)

Anyway, I’m yet again further on in the process without the original error. Interestingly, the changes I’ve made have resulted in the backend database remaining at a consistent size while the front end has ballooned to 2,097,152 KB. I had expected the process to crash when the front end reached the 2GB limit, but it is still going.

My understanding was that Access is quite poor at managing it’s file space, that updates, deletes etc do move / delete the data, but don’t free up the file space. However, I seem to be observing a situation where the absolute limit of Access size has been reached and the updates / deletes etc are still running, but can’t now increase the file size any more.

It’s ugly and I want to take the process to a point where the front end retains it’s minimal size, but if the process completes that is a major step forward.

Although I don’t think there’s liklihood of the queries resulting in cartesian joins, I will check that out, and look at indexes/primary keys. Interestingly, I removed indexes from some tables earlier as it seemed to be slowing the process down…

  • #18

While it is helpful to have the query run faster, will returning
duplicates possibly use less virtual/temp memory than excluding them?

Imagine you have a bunch of records, not indexed, and UNION checks that there are no duplicates. This entails, conceptually, checking each record against every other record! With ALL added, this entire process is skipped. I have had a crash on this (System resources something-or-other) which ALL fixed.

gemma-the-husky


  • #19

Update as of Wednesday AM. I’ve further refactored queries being used in the process to minimize use of sub queries and replaced the ultimate code used to write the schedule (using recordset.add / .update) with a db.execute sql where the sql is a dynamic append/insert values string.

I set this off yesterday evening. I’m getting a different error now… Run-time error 3073 Operation must use an updateable query. I think this is because the code is now running fast enough that the table is not released before the next append runs. I can handle that by error trapping or checking for presence of a lock file (or maybe by bringing that final table into the main backend database as well.)

Anyway, I’m yet again further on in the process without the original error. Interestingly, the changes I’ve made have resulted in the backend database remaining at a consistent size while the front end has ballooned to 2,097,152 KB. I had expected the process to crash when the front end reached the 2GB limit, but it is still going.

My understanding was that Access is quite poor at managing it’s file space, that updates, deletes etc do move / delete the data, but don’t free up the file space. However, I seem to be observing a situation where the absolute limit of Access size has been reached and the updates / deletes etc are still running, but can’t now increase the file size any more.

It’s ugly and I want to take the process to a point where the front end retains it’s minimal size, but if the process completes that is a major step forward.

Although I don’t think there’s liklihood of the queries resulting in cartesian joins, I will check that out, and look at indexes/primary keys. Interestingly, I removed indexes from some tables earlier as it seemed to be slowing the process down…

I think if you are getting to 2GB it will probably stop working. Who knows what errors you will get at that point. I tried to merge some databases as a project, which caused the database to reach 2Gb. At that point the dbs just became unusable. Tables could not be extracted and imported.

It depends how big your oracle dataset is, but I expect the underlying problem is more to do with the access manipulations.

just to clarify:

do you import the oracle tables into access? At that point, how big is the access database, before you try to process it at all?

The_Doc_Man


  • #20

Run-time error 3073 Operation must use an updateable query

This is not due to a table not being released. It is probably due to the presence of an aggregate in the query. Simple case: If I have a query that contains a SUM(x) field and and a GROUP BY y clause, the query cannot be updated because if you try to update a record, which one will you choose? Suppose, for S&G, that you have 10 records with «y» in that value being grouped. The UPDATE wants to only do one record update and this situation imposes a 10-way ambiguity. You would need to update the underlying table or query with a WHERE <field> = «Y» to catch all 10 fields.

There are other reasons that would cause this including queries based on a one-many JOIN where you didn’t select a field from the MANY side to help choose which unique record to update.

Понравилась статья? Поделить с друзьями:
  • Ошибка 3100 kyocera 2235
  • Ошибка 318 на климат контроле
  • Ошибка 3100 вольво
  • Ошибка 318 климатроник шкода октавия тур
  • Ошибка 3100 ваз