I have code to export MS Access (2016\2013) queries results into Excel spreadsheets that has worked for years.
This is the code (not posting all variables definitions I've on top of it):
strSQL = "select[query].* FROM [query] "
Set qdf = dbs.CreateQueryDef("MKTShare", strSQL)
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel12Xml, "MKTShare", "\\path\file.xlsx", _
True, ""
DoCmd.DeleteObject acQuery, "MKTShare"
The error given is 3251 - Operation Not Supported for This Object Type
I tried two machines, one running WIN10 and one WIN7. Same result. The really strange thing is that this problem arises mainly with crosstab queries. No issue with "standard" select queries. If I transform the xtabquery into table and then export that table, no issue but that this is an extremely inefficient solution as I've lots of query with very big datasets running in loop.
The query shows fine results if I run it from within Access. The problem is when it comes to the transferspreadsheet method.
It happened yesterday after some Windows updates.
I tried to workaround using Output, but it does not work with prefilled Excel templates as it screws up the whole file it is exporting to.
I just ran into this exact issue yesterday. The webpage for a Windows Update that was installed yesterday had a clue in it. It seems a new security related registry key was added to Jet/ACE to prevent connections to remote sources. Not sure why crosstab queries in a TransferSpreadsheet Export are affected (must be behind the scenes in how transfer spreadsheet works), but I can successfully run my command with this update uninstalled.
Here's the link to the update. It was distributed within an office security update (KB4493206).
https://support.microsoft.com/en-us/topic/kb5002984-configuring-jet-red-database-engine-and-access-connectivity-engine-to-block-access-to-remote-databases-56406821-30f3-475c-a492-208b9bd30544
Update: It's a bug introduced in the May 2021 security updates to the MSI versions of Office. Microsoft knows about it and is working on a bugfix. Quoting MVP Tom van Stiphout's answer in the MS Answers thread:
I heard back from MSFT. This is an issue with A2013 and A2016 MSI, and will be likely be fixed in the July update.
We have the same problem. I did some more debugging and managed to create a minimal reproducible example. Apparently, the problem only occurs
in Access 2013 with KB4493206 installed (probably in Access 2016 MSI with the corresponding KB installed as well, but I can't verify that, since I only have the C2R version of Access 2016),
when a crosstab query is exported with DoCmd.TransferSpreadsheet and
the query references an Access user interface control.
Here are the full repro instructions:
Create a new Access database.
Create a new table Table1 with fields ID (Long Integer) and MyText (Text) and the following records:
ID: 1, MyText: A
ID: 2, MyText: B
Create a new empty form Form1 with a text box Text0 and save it.
Open the form and enter 1 in the text box. Press "Tab" to "save" the value and leave the form open.
Create a new crosstab query CrosstabQuery1 with the following SQL:
PARAMETERS [Forms]![Form1]![Text0] Long;
TRANSFORM First(Table1.MyText) AS FirstValueOfMyText
SELECT Table1.ID
FROM Table1
WHERE ((([Forms]![Form1]![Text0])=1))
GROUP BY Table1.ID
PIVOT Table1.ID;
(Yes, that transformation is pointless and referencing form controls in queries is bad practice, but this is just a minimal repro example.)
Execute the crosstab query to confirm that it works. Save and close it. (Don't open it in design view, or you'll have to fix a few design-time-only things that don't affect the SQL before being able to save it.)
In the immediate window of the VBA code editor execute:
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel12Xml, "CrosstabQuery1", "C:\temp\repro.xlsx"
Expected result: The result of the crosstab query is exported to Excel.
Actual result (on Access 2013 with KB4493206 installed): Error "3251 - Operation Not Supported for This Object Type"
I have also reported this bug on the Microsoft forums.
I solved this issue by disabling caching for the database.
Related
After my Access got upgraded to Office 365 i'm starting to get write conflict issue whenever i edit a particular record. I was not getting this error in 2010 version.
Access database has 1 query used to filter out selected record for editing and 1 form (no subform). On some records i was able to update, but on some records i'm getting a write conflict. I'm using a run command DoCmd.RunCommand acCmdSaveRecord to save each record that is updated. Do you have an idea why changes are saved on some records and why a write conflict on some. There's no other users editing the record.
Thanks
Whenever I have issues with msaccess that I cannot explain, I do the following:
1-) Create a new msaccess empty file;
2-) Import all tables / queries / forms, objects to this new msaccess file
It normally solves this kind of issue.
I had this issue with some of my clients in the past; Most of the times it is resolved by applying the following instruction:
Select File > Options.
In the Access Options dialog box, select Current Database.
Under Application Options, select the Compact on Close check box.
Select OK.
Close and reopen the database for the option to take effect.
More details are here: https://support.microsoft.com/en-us/office/compact-and-repair-a-database-6ee60f16-aed0-40ac-bf22-85fa9f4005b2
You might have a bit field in your table that allows NULL, making it a triple-state field. Whenever you attempt to save your record, if it is null, it can raise this "Write Conflict" error.
The solution would be either to explicitly assign a value to it before saving, or use a default. Alternatively, if you have a bound control to it (like a CheckBox), set its Triple State property to False.
I'm trying to link an ODBC database - which I have no control on - in MS Access 2007 using a Machine Data Source - I don't know if that's relevant, from what I got this means that the access is set only on this computer -.
When I follow the wizard I can select the table but when the time comes to link it I get the error message:
The database engine can't find 'WTD.DATAPOINT_5/1000'. Make sure it is a valid parameter or alias name, that it doesn't include characters or punctuation, and that the name isn't too long
I think that the problem is that one of the field is named WTD.DATAPOINT_5/1000 and that Access interprets /as a symbol of its own.
The thing is that I don't even need the data stored in this column. Right now I don't know which way to go.
Find a way to tell Access that the / is part of the field name. (Highly improbable)
Retrieve only some fields from the table using built-in Access functions.
Set the connection manually using vba and retrieving only some of the fiels. If this is the way to go I would like some pointers as I have no idea where to start.
Solution number 2: use a passthrough SQL query.
Everything is explained in this tutorial.
Solution number 3: I tried to connect directly in VBA. The code bellow works like a charm for other tables but I still get an error for the table containing the problematic field.
Dim ConnectionStr As String
ConnectionStr = "ODBC;Driver={Oracle in OraHome92};Dbq=BLA1;Uid=BLA2;Pwd=BLA3;"
DoCmd.TransferDatabase acImport, "ODBC Database", ConnectionStr, acTable, "MyTable", "NewTable"
MS Access has limited capabilities to manage raw SQL queries: the editor is quite bad, no syntax highlighting, it reformats your raw SQL into a long string and you can't insert comments.
Debugging complex SQL queries is a pain as well: either you have to split it into many smaller queries that become difficult to manage when your schema changes or you end-up with a giant query that is a nightmare to debug and update.
How do you manage your complex SQL queries in MS Access and how do you debug them?
Edit
At the moment, I'm mostly just using Notepad++ for some syntax colouring and SQL Pretty Printer for reformatting sensibly the raw SQL from Access.
Using an external repository is useful but keeping there's always the risk of getting the two versions out of sync and you still have to remove comments before trying the query in Access...
For debugging, I edit them in a separate text editor that lets me format them sensibly. When I find I need to make changes, I edit the version in the text editor, and paste it back to Access, never editing the version in Access.
Still a major PITA.
I have a few tips that are specific to SQL in VBA.
Put your SQL code with a string variable. I used to do this:
Set RS = DB.OpenRecordset("SELECT ...")
That is hard to manage. Do this instead:
strSQL = "SELECT ..."
Set RS = DB.OpenRecordset(strSQL)
Often you can't fix a query unless you see just what's being run. To do that, dump your SQL to the Immediate Window just before execution:
strSQL = "SELECT ..."
Debug.Print strSQL
Stop
Set RS = DB.OpenRecordset(strSQL)
Paste the result into Access' standard query builder (you must use SQL view). Now you can test the final version, including code-handled variables.
When you are preparing a long query as a string, break up your code:
strSQL = "SELECT wazzle FROM bamsploot" _
& vbCrLf & "WHERE plumsnooker = 0"
I first learned to use vbCrLf when I wanted to prettify long messages to the user. Later I found it makes SQL more readable while coding, and it improves the output from Debug.Print. (Tiny other benefit: no space needed at end of each line. The new line syntax builds that in.)
(NOTE: You might think this will let you add add comments to the right of the SQL lines. Prepare for disappointment.)
As said elsewhere here, trips to a text editor are a time-saver. Some text editors provide better syntax highlighting than the official VBA editor. (Heck, StackOverflow does better.) It's also efficient for deleting Access cruft like superfluous table references and piles of parentheses in the WHERE clause.
Work flow for serious trouble shooting:
VBA Debug.Print > (capture query during code operation)
query builder > (testing lab to find issues)
Notepad++ > (text editor for clean-up and review)
query builder > (checking, troubleshooting)
VBA
Of course, trouble shooting is usually a matter of reducing the complexity of a query until you're able to isolate the problem (or at least make it disappear!). Then you can build it back up to the masterpiece you wanted. Because it can take several cycles to solve a sticky problem, you are likely to use this work flow repeatedly.
I wrote Access SQL Editor-- an Add-In for Microsoft Access-- because I write quite a lot of pass-through queries, and more complex SQL within Access. This add-in has the advantage of being able to store formatted SQL (with comments!) within your Access application itself. When queries are copied to a new Access application, formatting is retained. When the built-in editor clobbers your formatting, the tool will show your original query and notify you of the difference.
It currently does not debug; if there was enough interest, I would pursue this-- but for the time being the feature set is intentionally kept small.
It is not free for the time being, but purchasing a license is very cheap. If you can't afford it, you can contact me. There is a free 14-day trial here.
Once it's installed, you can access it through your Add-Ins menu (In Access 2010 it's Database Tools->Add Ins).
Debugging is more of a challenge. If a single column is off, that's usually pretty easy to fix. But I'm assuming you have more complex debugging tasks that you need to perform.
When flummoxed, I typically start debugging with the FROM clause. I trace back to all the tables and sub-queries that comprise the larger query, and make sure that the joins are properly defined.
Then I check my WHERE clause. I run lots of simple queries on the tables, and on the sub-queries that I've already checked or that I already trust, and make sure that when I run the larger query, I'm getting what I expect with the WHERE conditions in place. I double-check the JOIN conditions at the same time.
I double-check my column definitions to make sure I'm retrieving what I really want to see, especially if the formulas involved are complicated. If you have something complicated like a coordinated subquery in a column definition
Then I check to see if I'm grouping data properly, making sure that "DISTINCT"'s and "UNION"'s without UNION ALL don't remove necessary duplicates.
I don't think I've ever encountered a SQL query that couldn't be broken down this way. I'm not always as methodical as this, but it's a good way to start breaking down a real stumper.
One thing I could recommend when you write your queries is this: Never use SELECT * in production code. Selecting all columns this way is a maintenance nightmare, and it leads to big problems when your underlying schemas change. You should always write out each and every column if you're writing SQL code that you'll be maintaining in the future. I saved myself a lot of time and worry just by getting rid of "SELECT *"'s in my projects.
The downside to this is that those extra columns won't appear automatically in queries that refer to "SELECT *" queries. But you should be aware of how your queries are related to each other, anyway, and if you need the extra columns, you can go back and add them.
There is some hassle involved in maintaining a code repository, but if you have versioning software, the hassle is more than worth it. I've heard of ways of versioning SQL code written in Access databases, but unfortunately, I've never used them.
If you're doing really complex queries in MS Access, I would consider keeping a repository of those queries somewhere outside of the Access database itself... for instance, in a .sql file that you can then edit in an editor like Intype that will provide syntax highlighting. It'll require you to update queries in both places, but you may end up finding it handy to have an "official" spot for it that is formatted and highlighted correctly.
Or, if at all possible, switch to SQL Server 2005 Express Edition, which is also free and will provide you the features you desire through the SQL Management Studio (also free).
Expanding on this suggestion from Smandoli:
NO: DoCmd.RunSQL ("SELECT ...")
YES: strSQL = "SELECT ..."
DoCmd.RunSQL (strSQL)
If you want to keep the SQL code in an external file, for editing with your favorite text editor (with syntax coloring and all that), you could do something like this pseudo-code:
// On initialization:
global strSQL
f = open("strSQL.sql")
strSQL = read_all(f)
close(f)
// To to the select:
DoCmd.RunSQL(strSQL)
This may be a bit clunky -- maybe a lot clunky -- but it avoids the consistency issues of edit-copy-paste.
Obviously this doesn't directly address debugging SQL, but managing code in a readable way is a part of the problem.
Similar to recursive, I use an external editor to write my queries. I use Notepad++ with the Light Explorer extension for maintaining several scripts at a time, and Notepad2 for one-off scripts. (I'm kind of partial to Scintilla-based editors.)
Another option is to use the free SQL Server Management Studio Express, which comes with SQL Server Express. (EDIT: Sorry, EdgarVerona, I didn't notice you mentioned this already!) I normally use it to write SQL queries instead of using Access, because I typically use ODBC to link to a SQL Server back end anyway. Beware that the differences in the syntax of T-SQL, used by SQL Server, and Jet SQL, used by Access MDB's, are sometimes substantial.
Are you talking here about what MS-Access calls 'queries' and SQL call 'views' or about the 'MS-Access pass-through' queries which are SQL queries? Someone could get easily lost! My solution is the following
free SQL Server Management
Studio Express, where I will
elaborate and test my queries
a query table on the client
side, with one field for the query
name (id_Query) and another one
(queryText, memo type) for the
query itself.
I then have a small function getSQLQuery in my VBA code to be used when I need to execute a query (either returning a recordset or not):
Dim myQuery as string, _
rsADO as ADODB.recorset
rsADO = new ADODB.recordset
myQuery = getSQLQuery(myId_Query)
'if my query retunrs a recordset'
set rsADO = myADOConnection.Execute myQuery
'or, if no recordset is to be returned'
myADOConnection.Execute myQuery
For views, it is even possible to keep them on the server side and to refer to them from the client side
set rsADO = myADOConnection.execute "dbo.myViewName"
Well to my knowledge there are 2 options:
Notepad++ with Poor man's t-sql formatter plugin ..i know there is already a mention for SQL Pretty Printer but i haven't used it..so my workflow is ..i create the query in Access..i copy paste it to Notepad++ ...i format it..i work on it ...back to Access..only issue..it pads in some cases spaces in this case : [Forms]![AForm].[Ctrl] and they become [Forms] ! [AForm].[Ctrl] but i am used to and it doesn't bother me..
SoftTree SQL Assistant (http://www.softtreetech.com/sqlassist/index.htm) bring just about everything you wanted on a SQL editor...i have worked a bit in the past(trial) but its price tag is a bit stiff
I have an Access application that use the classical front-end/back-end approach. Yesterday, the backend got corrupted for a reason I don't know. So I opened the backend with Access 2003 and access asked me if I wanted to repair the file, I said yes and it seemed to work.
I can open the database see the tables contents and run most of the queries.
However there is an access query that doesn't work with a specific where clause.
Example :
// This works in the original DB, but not in the compacted one :
SELECT a, b, c
FROM tbl1 INNER JOIN tbl2 ON tbl1.d = tbl2.d
WHERE e = 3 AND tbl2.f = 1;
// This works in both the original and the compacted one :
SELECT a, b, c
FROM tbl1 INNER JOIN tbl2 ON tbl1.d = tbl2.d
WHERE e = 3;
When I try to run the queries, nothing happens. The access process start to use most of the CPU and the GUI stop responding. If I run the query from the query editor, I can use Ctrl+Break to stop the execution. I tried to give the query lot of time and it didn't help.
I've checked the execution plan in showplan.out and it seems correct (at least it should not takes forever to execute)
I tried to compact the DB again. I tried to import the tables in a new DB. I even tried to import the tables and their data in a mdb file that was in a now good state (from a backup).
Anyone have an idea?
Sounds like an index was corrupted and when that happens, it's dropped during the compact. Check for a system table called MSysCompactErrors -- you'll have to show hidden objects and/or system objects in Tools | Options | VIEW.
Never compact a Jet MDB without making a backup beforehand. Because of that rule, the COMPACT ON CLOSE function is completely useless, as it's not cancellable, so you always make sure it's turned off in all MDBs.
I don't know what type of meta data Access brings along when it imports a table from one database into another one. If the meta data is corrupted, importing the table to another database wouldn't necessarily resolve the problem. If practical, you might try creating the tables from scratch in a brand new database and then just exporting and importing (or copying and paste appending) the data into the new database.
I've never seen a table get corrupted like this in such a small database, although with Access anything is possible. Could there be something wrong with the data?
I'd try recreating the query fresh (new name, etc.), and see what happens.
You could even try copying it (even within the same DB or to a brand new one). If that works, the worst case scenario is you have to copy all the objects across to a new DB.
Is there an index on the field tbl2.f?
Also try going into that table in datasheet view, sort tbl2.f in ascending sequence and see if there is anything really strange in the first or last records.
Do you have access to a SQL Server installation? You could use the Upsizing Wizard under the Tools -> Database Utilities menu to copy the data to SQL Server, and see if you get the same problem there.
I'm encountering a problem where DoCmd.OutputTo acOutputQuery deletes the query itself the second time it is run.
Is there any workaround/patch for this bug (at least seems like a bug to me)?
Re: your comment.
Did you do a file copy, or did you copy the objects between two databases? IF the second, you might want to try doing a compact and repair on a file-copy of the original.
You might even want to try that on the real original.
I think the behaviour you described "...deletes the query itself, the second time it is run" occurs when the query returns no records.
even 2007 has this problem, it is happening to me also, but very randomly. Sometimes I can run it many times before the bug happens, other times it happens right away, it's a small database, 29 records, and a tiny query, so it's definitely a bug in access
I know it's been awhile since the original post, but I have found a solution that I did not see here. I'm using Access 2010. It seems that almost everytime I execute DoCmd.OutputTo acOutputQuery..., my saved query still appears in my list of queries, but the SQL gets wiped out, which subsequently deletes my output file too from the network.
I just reset the SQL before calling DoCmd.OutputTo acOutputQuery...
CurrentDb.QueryDefs("MyQuery").SQL = "SELECT..."
and then call
DoCmd.OutputTo acOutputQuery, "MyQuery"...
So far so good.
it happens to me too.
I'm using Access 2003.
The only workaround I've found is to preserve a copy of the original mdb, this way I can restore the mdb when it happens.
It seems that Access 2007 doesn't have this problem.
Another workaround is to change the original query to a make table query, and then use
DoCmd.OutputTo acOutputTable, TableName, ...
It means you have an extra table hanging around, but you could always do a delete table in code or via a query afterwards to clean up.