I was helping a non-profit migrate MS-Access data to MYSQL. So, I ported data to MYSQL and created links in ms-access to MYSQL tables using ODBC. Majority of the existing SQL works fine. However I am stumped on this one error -
You have an error in your SQL syntax check the manual that corresponds to your MySQL server version for the right syntax to use near UNION...
I have stripped the SQL with 7 UNIONS to bare bones where it still fails.
(SELECT 1 as A FROM Households H)
UNION ALL
(SELECT 2 as A FROM Households H)
UNION ALL
(SELECT 3 as A FROM Households H)
The part that is getting to me is that I am able to run above successfully as long as I run only one UNION meaning below SQL, but the moment I add a third one, it gives ODBC error
(SELECT 1 as A FROM Households H)
UNION ALL
(SELECT 2 as A FROM Households H)
I tried using ` or ' or [] but none of these helped. The reason I am frustrated with this error is that either it should fail with all or none, it gives an error only when using two or more UNION clauses. Could this be a potential bug in driver?
I am using mysql-64 bit on win-7 64bit with ms-access and a 32-bit driver. It shouldn't be an architecture problem as I am able to run other queries with multiple UNIONs, and accessing the same set of tables.
It would be great if someone can give pointers on how to debug this further.
In my version of Access, when I edit a query in Design (SQL) view there are three buttons at the top. "Union", "Pass-Through", and "Data Definition".
If I click "Pass-Through" your query works. If I click "Union" it breaks. Can you get away with using "Pass-Through" for this query?
Even in "Union" or "Data Definition" mode, this seems to work:
(SELECT 1, column1 as A FROM Households H)
UNION ALL
(SELECT 2, column2 as A FROM Households H)
UNION ALL
(SELECT 3, column3 as A FROM Households H);
Maybe Access is confused by only a single column?
Alternatively, just use a a multiplex table instead of a union:
SELECT mux.id,
IIf(mux.id=1,column1,IIf(mux.id=2,column2,column3)) AS A
FROM Households, mux;
Note: mux table should have 3 values in it 1,2,3. If it has more, you'd want to limit to the first 3 (or n) in a where clause.
It is a known MySQL problem: more than two UNION SELECT statement problem (with MS Access) but I don't know if the problem is in the MSAccess SQL parser (which compiles to ODBC SQL), or in the MySQL ODBC driver (which compiles ODBC SQL to MySQL SQL)
To work it out, I'd have to look at the ODBC log, and the ODBC specification, and see if Access was emmitting valid ODBC SQL.
That would be a waste of effort, since it makes more sense to use a pass-through query anyway. The main reason for using a native MSAccess query in this place would be to join to different data sources - for example, an Excel Spreadsheet and a MySQL table -, and according to the comments on the MySQL bug report, the problem goes away when you do that.
I am not sure about where the problem lies, but I think (though it's only an assumption) that this is on MS Access side. I had two UNION queries, each of them was putting some other queries together. Both used somewhat complicated sub-queries so I had lots of problem to create a pass-through query and I didn't want to use MySQL "views".
Surprisingly one of my queries worked, the other showed an error. My idea is that the working query used some Access features while the other was some kind of SELECT ... FROM's .
I don't know the rules but I think that when your query is simple, Access sends it to external database engine and puts one more bracket and causes an error. If you do a comlicated query, Access gets all data it needs and makes all necessary operations itself. For example, you may try to create a pivot query, that uses MSSQL TRANSFORM statement, which does not exist in MySQL, so it is obvious that Access handles it itself. So why couldn't it make SELECT by itself? I don't know. Maybe some performance reasons?
My working query differed from the other that it had one more (string) field that was calculated by built-in Access function. It used also Access & operator, which has another meaning (logical AND) in MySQL. (By the way to join strings in MySQL use CONCAT function). They of course need to be evaluated by Access, because MySQL does not understand this method of joining strings together.
I suggest just to make UNION not from tables, but from queries (like SELECT * FROM tablename and nothing more) and giving them a field that you don't need but that will force Access to handle the query. So a query (in Access) should look like this:
SELECT tablename.*, [somefield1]&[somefield2] AS useless_field FROM tablename;
(in my Access 2000 operations like "a" & "b" or IIf(true;true;false) were probably simplified and solved, so it didn't work. I think one needs at least one dynamic field to evaluate. I also did no performance tests. Probably it would be fastest if you add to integers, maybe just increase your index by 1?).
Then, of course, you join it together:
SELECT * FROM query1
UNION ALL
SELECT * FROM query2
UNION ALL
SELECT * FROM query3
UNION ALL
...
SELECT * FROM queryn
;
You don't need this useless_field of course.
I agree that this is a workaround but I have no other ideas.
Related
I am currently working on a query in Access 2010 and I am trying to get the below query to work. I have the connection string between my local DB and the server that I am passing through to working just fine.
Select column1
, column2
from serverDB.dbo.table1
where column1 in (Select column1 from tbl_Name1)
In this situation table1 is the table on the server that I am passing through to get to, but the tbl_Name1 is the table that is actually in my Access DB that I am trying to use to create constraints on the data that I am pulling from the server.
When I try to run the query, I am getting the error that it doesn't think tbl_Name1 exists.
Any help is appreciated!
I just came across a solution that may help others in a similar situation.
This approach is easy because you can just run one query on your local Access database and get everything you need all at once. However, a lot of filtering/churning-through-results may be done on your own local computer behind the scenes, as opposed to on the remote server, so it may not necessarily be quick.
Steps
Create a query, make it a "Pass Through" query, and set up its "ODBC Connect Str" property to connect to the remote database.
Write the pass through query, something like SELECT RemoteId From RemoteTable and give your pass through query a name, maybe PassThroughQuery
Create a new query, make it a regular "Select" query.
Write your new query, using the pass through query you just created as a table in this new query (seems weird to use a query as a table, but it works) and join that PassThroughQuery "table" to your local table and filter it based on values in the local table, something like SELECT R.RemoteId, L.LocalValue FROM PassThroughQuery R INNER JOIN LocalTable L ON L.LocalId = R.RemoteId where L.LocalValue = 'SomeText'
This approach allows you to mix/join the results of a pass through query and the data in a local Access database table cleanly, albeit potentially slowly if there is a lot of data involved.
I think the issue is that a pass through query is one that is run on the server. Since one of the tables is located on the local Access file, it won't find the table.
Possible workaround if you must stay with the pass-through is you can build an SQL string with the results of the nested query rather than the query string itself (depending on the number of results this may or may not be practical)
e.g. Instead of Select column1 from tbl_Name1 you use "c1result1","c1result2",....
Before I begin, I realize that what I'm attempting is bizarre and hackish. It's just for an isolated pen test, specifically SQL Injection.
What I need to do is write a SQL statement that behaves differently when executing on a MySQL database than it does when executing on a SQL Server Database.
Edit
The limitation of the Query I can build is that I can only change what's after the "WHERE id =" clause. I can't affect any other part of the query. Specifically, I need to be able to attach a " UNION SELECT * FROM some_other_table" that only gets executed by the SQL server to the end of my input.
This obviously would blow up MySQL because it doesn't have the tables I'm unioning.
Specifically:
SELECT * FROM USERS
WHERE id = My input -> (MySQL code: 'x' or 1=1 )
(MSSQL code 'x' or 1=1 UNION SELECT * FROM table)
The problem is, if either statement gets executed by the database it wasn't meant for, it blows up (and not in the way I need it to).
This lead to my discovery of Conditional/Executable Comments in MySQL.
SELECT * FROM USERS
WHERE id = /*! This will be executed but only by mysql */
That's great but I still can't prevent MySQL from executing MSSQL! I can only stop MSSQL from executing MySQL code.
My initial idea was to have a comment inside the MySQL conditional like:
SELECT * FROM USERS
WHERE id = /*! 4 or 1=1 --*/ MSSQL code that is ignored by mysql
But this throws an error saying to check my syntax at a line with nothing on it near ''.
I don't fully understand why this doesn't work but I know doesn't work with any form of MySQL comment I know of (Tried #, /*).
Is there a way to get my strange SQL statement to work? Or is there a way to do a conditional comment in MSSQL? I really just need MySQL to ignore anything after it's conditional but I have no idea how to make that happen without comments.
I'm not sure if this is what you need, but if I understand correctly you want one SQL statement that returns different results on MySQL vs. SQL Server (if that's what "behaves differently" means?). If so, one place to start would be using a system function that has the same name and syntax but different behaviour, such as SUBSTRING():
select substring('test', -1, 1)
On SQL Server that returns an empty string, but on MySQL it returns t. I don't know if using SUBSTRING() is viable in your case, but if not you may be able to find another function that's easier to use in your query.
If this doesn't help at all then I suggest you provide some more details about what limitations you have in building your query.
I am executing queries from Access 2010 on an Interbase database via ODBC (Easysoft) ver.7. Everything works fine except when i come to fire a Union query such as this:
SELECT TRIP.TRIPDATE, RESERVATION.BOOKINGREF, RESERVATION.LEADNAME, TRIP.DRIVERID, RESERVATION.STATUS, RESERVATION.DATECANCELLED, TRIP.TRANSPORTTYPEID
FROM TRIP INNER JOIN RESERVATION ON TRIP.TRIPID = RESERVATION.ARRIVALTRIPID
WHERE (((TRIP.TRIPDATE) Between #2/1/2012# And #2/29/2012#) AND ((TRIP.DRIVERID)=2) AND ((RESERVATION.DATECANCELLED) Is Null) AND ((TRIP.TRANSPORTTYPEID)=12))
UNION
SELECT TRIP.TRIPDATE, RESERVATION.BOOKINGREF, RESERVATION.LEADNAME, TRIP.DRIVERID, RESERVATION.STATUS, RESERVATION.DATECANCELLED, TRIP.TRANSPORTTYPEID
FROM TRIP INNER JOIN RESERVATION ON TRIP.TRIPID = RESERVATION.DEPARTURETRIPID
WHERE (((TRIP.TRIPDATE) Between #2/1/2012# And #2/29/2012#) AND ((TRIP.DRIVERID)=2) AND ((RESERVATION.DATECANCELLED) Is Null) AND ((TRIP.TRANSPORTTYPEID)=12));
When I run this query from Access I get
"ODBC --call failed, [Easysoft][Interbase]Dynamic SQL Error, SQL error
code = -104, Token unknown -line1,char 0, ((#-104)"
When running the select queries on their own they work fine but when joined via UNION I get this error.
Any help would be appreciated.
thanks
You don't mention if your query is a passthrough query or if you are using linked ODBC tables in an Access query.
If you are using a normal Access query
When using linked ODBC tables in a normal Access query, the Access data engine will rewrite the queries as necessary to make them compatible with the other database engine.
Sometimes, it can fail though.
Make sure each SELECT query works and returns correct data independently.
Try a simpler UNION query to make sure that the issue comes from the UNION keyword itself.
Try UNION ALL
Try using a pass-through query instead.
If you are using a pass-through query
Pass-through queries are send verbatim to the ODBC engine, and Access just collects the results without rewriting the query itself.
Make sure each SELECT query works as a pass-through query and returns correct data independently.
Make sure that the literal dates are properly formatted for Interbase SQL.
The ones you use are correct for Access SQL, but different databases accept different formats.
Try a simpler UNION query using simple SELECT statements involving 1 or 3 fields only.
Try UNION ALL.
You don't show it in your question, but just in case, if you used an ORDER BY statement, you have to wrap the UNION query.
Try to cast the data types of your fields. It may be that some fields's data are incorrectly interpreted and that the union fails because it assumes that the data retrieved is of different types.
Try using a standard Access query instead.
What is the best thing to approach something like:
select * from (show tables like "T_DATA___") // Invalid
There are over 600 tables with the name T_DATAxy where x and y are letters
Something went seriously wrong with this design. Accessing 600 tables at once means accessing as much as 1800 files on disk. You should've partitioned this data instead.
As far as th question goes, Im afraid that you will need to use a stored procedure or external application, to build a multiple UNION query statement. Still, I seem to remember that there's a limit of 32 tables merged in a UNION.
You could get the list of tables whose data you want (show tables like __) and then use mysql dump, passing in that list.
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html
If you are determined to get it from SQL queries, you could generate appropriate sql queries using macros and execute them all at once. e.g. get the list of tables, replace newline with "; (newline) select * from ", execute all queries. (The emacs mysql mode makes this super easy).
As the other commenter says, you won't be able to do it in a single query due to #-table limits.
I want to my make a search-statement and query things like this
select * from table where col like '%vkvk%'
But with trial and error I've come to the conclusion that access doesn't work with LIKE or
wildcard operators. Does anybody have some other solutions because I ain't so in to access actually, so I really don't know.
Try:
select * from table where col like '*vkvk*'
Use an asterisk for the wildcard character.
If you want to use some SQL syntax that is like SQL Server, go to your Access OPTIONS and set it for "SQL 92" mode. So far as I know, this does two main things (there may be others):
allows you to use % and _ as wildcards instead of Jet SQL's * and ?.
allows you to use the non-crazy derived table syntax:
SELECT MyTable.*
FROM (SELECT * FROM SomeTable) As MyTable
...instead of the bollixed-up Jet method:
SELECT MyTable.*
FROM [SELECT * FROM SomeTable]. As MyTable
...which has problems with table and field names with spaces in them, since you have to use brackets inside the derived table definition, which breaks the Jet syntax entirely.
As I said, there may be other things it changes, but if you're a SQL Server programmer, you may find it easier to set SQL 92 mode on. On the other hand, most Access help uses Access/Jet/ACE conventions, so you may end up more confused by trying to use it.
EDIT:
Since originally posting this, I've discovered that there are problems with turning on SQL 92 mode in an existing Access application. The two I discovered were:
It changes the list of reserved words, which means that SQL that previously worked with the SQL 89 list of reserved words can break (if it uses a SQL 92 reserved word).
It can break multi-column combo boxes with a hidden first column (which is a very common UI object in Access applications). Specifically, it breaks the Autoexpend/autoselect behavior.
There may be other problems, but I discovered these accidentally when I turned on SQL 92 mode in a client project to test something for SO and forgot to turn it off when I distributed the next update. Fortunately, the problems were quickly detected, and it didn't take me too long to idenfity SQL 92 mode as the cause of the problems.
In short, I don't consider SQL 92 mode in Access to be of use to anybody at all. It's a feature aimed at people who won't be using Access interactively in the first place, seems to me.
like '%kvk%' sometimes work sometimes don't
With Access 2010 with sql server (2008) linked tables
Use '*kvk*'
I tried several "Like" syntax on one request, (I'm using VB.NET and a MS-ACCESS 2010 database), and none of them could get any other result than throwing an exception.Why? I'm not having any idea about that.
I did this workaround that could be useful on some similar cases:
Instead of
SELECT dbFieldDisplayName FROM dbTableName WHERE dbFieldSearchName Like 'A*'
I Used:
SELECT dbFieldDisplayName FROM dbTableName WHERE dbFieldSearchName >='A' AND dbFieldSearchName <'AZZZ'