-1

My company uses Microsoft Access linked to MySQL tables to isolate employees from accidentally breaking any of the tables.

A query that runs weekly has started malfunctioning and when I dug in and ran it manually I got the MySQL Errcode: 28 (#3) Error writing file '/tmp/path error alert which I've seen many people say is the result of a lack of storage space on the server that MySQL is installed on.

Some people involved are wanting to take the query that currently runs on Access and write it into the VBA to query the MySQL tables directly and bypass Access. Their reasoning is that this could be caused by the Access 2gb return limit instead of an underlying storage shortage on the server side.

It seems to me that Access has its own way of telling the user that the return is too large and wouldn't need to piggyback off of a well-established/understood MySQL error.

So, my question is, is it possible that this is an Access issue disguised as a MySQL issue? I would like to know from someone more experienced before I spend the rest of the week rewriting queries that are still not going to work because we aren't addressing the underlying problem.

Thank you.

OrthoProj
  • 15
  • 4
  • My understanding of 2GB limit is Access file size, not memory. Per MS "You can work around this size limitation by linking to tables in other Access databases." MS also states recordset size is limited to 1GB. – June7 Mar 23 '22 at 18:41
  • What kind of query is this (SELECT, UPDATE, ...)? Running the query from VBA won't change anything, running a Pass-Through query probably will. – Andre Mar 24 '22 at 01:18

1 Answers1

0

It's possible that this is due to the ODBC driver making an inefficient MySQL query out of an Access query but my guess is that this is purely a MySQL problem. Particularly if by "I dug in and ran it manually" means you bypassed Access and ran the query directly in MySQL and got error 28. Try some of the solutions here:

MySQL/Writing file error (Errcode 28)