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'
Related
I am using an OleDbConnection, OldDbCommand, and OleDbReader against an Access database.
I have a named query in the database which I am calling from the code.
The query works correctly when it is ran from access.
Several resources indicate the error could be caused by using reserved words in the query and to wrap them with brackets. I am not using any reserved words and have wrapped all column names in brackets anyway to rule it out.
Trying to determine where the problem is, I have simplified the query to a simple
SELECT id FROM table1 WHERE id = 5
which the Ole connection does not throw an exception.
When I introduce the next portion of the query:
SELECT table1.id FROM table1 INNER JOIN storedQuery ON table1.id = storedQuery.id WHERE table1.id = 5"
then I get the exception.
The exception details are as follows:
Message: IErrorInfo.GetDescription failed with E_FAIL(0x80004005).
ErrorCode: -2147467259
NativeError: -533136361
SQLState: 3000
I apparently was mistaken when I said the query did not contain any reserved words.
The query I was using was selecting from another query in the Access Database. That other query had a reserved keyword that was causing the problem.
BTW:
The Access database engine runs in different modes, depending on whether it is called from Access, data access objects, the Microsoft OLE Provider for the Access database engine, or the Microsoft Access ODBC driver. It can be run in either ANSI mode or non-ANSI (traditional) mode.
Because using these two modes results in two slightly different sets of reserved words, a query that uses a reserved word might work in one mode and fail in another mode
Access 2007 reserved words and symbols
Keith
..and have wrapped all column names in brackets anyway to rule it out.
Not only columns names that should be surrounded by square brackets
Table names should as well
For example, replace the below line
SELECT id FROM table1 WHERE id = 5
With the below line
SELECT [id] FROM [table1] WHERE [id] = 5
Another possible cause of this exception is if the File your trying to load/read does not exist.
I have found it useful to perform a "File.Exists" before trying to open the file just to make sure my code detects this specific cause of the "IErrorInfo.GetDescription failed with E_FAIL" exception correctly.
My problem was a reserved word in this instance Domain. With so many reserved words it is difficult to debug.
My solution was in visual studio using the "Data Source" then building a query, it automatically detected the reserved word and put [] around it so it looked like Orders.[Domain]. You don't have to put brackets around your table.
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.
I must understand few things about MS access queries, and this is why I'm coming here.
First of all - my task list is written in Latvian (hate that), this is why I can't understand simple things.
Here is my one of tasks: "Make four simple queries, where shows specific, not-specific, number intervals, less than and greater than."
Probably I didn't translated my task correctly, but I can't understand, what does means specific and not-specific query.
This is too simple for me, and this is why I don't get it.
And also I wanted to ask, if there is any SQL commands, which does the same thing like in PHP function substr(). As I tried to use SQL commands, which I use daily writing MySQL queries, does not work in MS Access.
I hope, that some one could help me about this :) Thanks!
/Rob
Here are some references that may help:
Fundamental Microsoft Jet SQL for Access 2000
Intermediate Microsoft Jet SQL for Access 2000
Advanced Microsoft Jet SQL for Access 2000
As for substr, you can use Mid, Left, Right, InStr and InstrRev.
I work for a company where we likely going to update from Access97/2003 to Access2010.
After playing around with a prototype, I have found an issue when using Access 2010 with databases created in Access 2003.
Under some conditions, existing queries/SQL's in Access 2003 will become unusable in Access 2010. Here a small example:
Tablename: Parameters Field names: Number, Value
A query created with Access 2003 query designer:
SELECT Parameters.Value
FROM [Parameters]
WHERE (((Parameters.Number)=100));
this works fine with Access 2003.
In Access 2010 a error is raised: Syntax error in PARAMETER clause
A workaround for the error is to change the view in Access 2003. Here we get rid of the brackets:
SELECT Parameters.Value FROM [Parameters] WHERE Parameters.Number=100;
This will work in Access 2010 but the query remains unchangeable in the designer, because the query designer creates the syntax shown above.
The reason for this error is in fact the use of the reserved word 'Number', which shoudn't be used when you start to build a table or query, but for a migration with hundreds of existing databases, it is very likely or at least a risk to change the Access version without a complete test.
My idea is to write a small program which opens all the existing views and the tables to check if they work fine.
Anyway, dose anybody have a better solution for this, or is there a tool to check MS-Access 2003 databases to be compatible with Access 2010?
Many thanks in advance
Jörg
Parameters, Value, and Number are all reserved words. You may be right that Number is the culprit here; I would have suspected Parameters as more likely to confuse Access in a query.
"For a migration with hundreds of existing databases", first evaluate them with Allen Browne's Database Issue Checker Utility. In addition to the reserved words issue, it will give you an idea of other potential problem areas. Whether those issues will be more troublesome in Access 2010 than in 2003 is an open question.
However I don't see an easy solution for your predicament. You have hundreds of databases with perhaps thousands of tables and queries ... if they routinely incorporate reserved words for table and field names, as well as other object names ... your situation is miserable.
Experiment on a copy of an existing database. Turn on "track name autocorrect" and let it build the object dependencies. Change the table definitions to eliminate reserved words. Then see how much extra work you need to find and fix the items autocorrect didn't do for you. But don't leave autocorrect turned on in any application you release to your users.
BACKGROUND:
I have an Access 2007 application, with a form which builds a Filter string to pass to a Report, which uses a stored query.
In Access Options, I have "SQL Server Compatible Syntax (ANSI 92)" checked for This database, and the Filter string includes a LIKE clause with % wildcard characters.
ISSUE:
Randomly when I save or open the application (not sure the exact cause), the effective wildcard syntax switches from needing % to *, or back. I know this because my query stops working.
WHAT I'VE TRIED:
I do a find/replace on the wildcard characters, it works for a while, and then it happens all over again, without making any significant changes to the query or filter.
Plenty of Compact/Repairs have made no difference.
Any ideas?
If you are only using ANSI-92 Query Mode for the alternative wildcard characters (rather than the enhanced SQL DDL and DCL SQL syntax it offers) then consider using the ALIKE keyword in place of the LIKE keyword.
The advantage is that you can use the ANSI-92 Query Mode wildcard characters in either Query Mode. The slight disadvantage is that the ALIKE is officially unsupported, meaning it might disappear in a future release of the engine (though I would rate this as low risk myself).