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.
Related
Using SSRS with VS 2017 I am receiving the ORA-01008 not all variables bound message when connecting to Oracle via the ole db connector. The code works normally through sql developer. Similar code worked fine in VS 2016 before we upgraded to vs 2017. Any ideas what's causing this issue
Code:
select tr.id_number
FROM rpt_transaction_view TR
WHERE TR.unit_code=:pUnit
Error Message:
TITLE: Microsoft SQL Server Report Designer
An error occurred while executing the query.
ORA-01008: not all variables bound
ORA-01008: not all variables bound
ADDITIONAL INFORMATION:
ORA-01008: not all variables bound
ORA-01008: not all variables bound (OraOLEDB)
BUTTONS:
OK
A little late BUT I think I found a solution (if you want to call it that). A little background, I've been working with SSRS since BIDS and have NEVER encountered this error before... until today. I have spent hours googling, trying to find what the solution is and NOTHING worked.
Now, I build all my queries in Oracle SQL Developer, and noticed something different about the offending query - the "SELECT" was underlined, basically Oracle SQL Developer wanted to rewrite the query, so I let it. Now I had two parameters, we'll call them :p1 and :p2, each being used three times throughout the query. When the query was re-written (to something almost unreadable) it replaced the parameters with :b1, :b2, :b3, :b4, :b5 and :b6. All odd parameters (:b1, :b3 and :b5) were :p1 and the evens :p2. I used a find and replace so I was back to only using the 2 parameters. I replaced the dataset in my report with this query, ran it and voila error gone...
Why? I have not the slightest idea. It's not like this query was unique to other queries I've used. I have over 400 oracle based reports and I've never had to do anything like this and this query wasn't as nearly as complicated as others I've written. I have some queries that use the same parameters a half dozen times and no issue - just this one.
Anyways, thought I would share in case anyone else was 100% stumped as I was.
I am attempting to create several calculated columns in a table with different parts of a parsed filename. Using the InstrRev function is critical to isolate the base file name or extension, but InstrRev is not supported in calculated columns.
I know that there are other ways to solve my problem that don't use calculated columns, but does anyone have a valid calculated column formula that could help me?
Access lets you use VBA functions (including user-defined functions) directly from within a SQL query - however they only work within an Access context - if you have another frontend for a JET (now ACE) database - or inside a computed/calculated column, they won't work - as you've just discovered.
Unfortunately Access (JET and ACE) have only a very meagre and anaemic selection of built-in functions, and the platform has now lagged-behind SQL Server (and even the open-source SQLite) significantly - Access 2016 has not made significant changes to its SQL implementation since Access 2000 (16 years of stagnation!) whereas SQL Server 2016's T-SQL language is so evolved it's almost unrecognizable compared to SQL Server 2000.
JET and ACE support the standard ODBC functions ( https://msdn.microsoft.com/en-us/library/bb208907(v=office.12).aspx ) however none of these perform a "reverse index-of" operation. Also absent is any form of pattern-matching function - though the LIKE operator works, it only returns a boolean result, not a character index.
In short: what you want to do is impossible.
This has been discovered by many people before you:
https://social.msdn.microsoft.com/Forums/office/en-US/6cf82b1b-8e74-4ac8-9997-61cad8bb9310/access-database-engine-incompatible-with-instrrev?forum=accessdev
He maintains a list of DAO/Jet/etc reserved words - and on that list you will see the InstrRev is a VBA() function, and is not a part of the Jet/Ace Engines.
using InStrRev() and similar functions in Jet/ACE queries outside of Access
As you have discovered, SQL queries executed from within Access can use many VBA functions that are not natively supported by the Jet/ACE dialect of SQL
That said, computed/calculated columns are only really of use in stored VIEW objects ("Queries" objects in Access parlance) - which in turn are used for user convenience, not for any programming advantage - especially as these are scalar functions that are evaluated for every row of data that the engine processes (making them potentially very expensive and inefficient to run).
...so the only real solution is to abandon computed/calculated columns and perform this processing in your own application code - but the advantage is that your program will likely be significantly faster.
...or don't use Access and switch to a different DBMS with better active support, such as SQLite (for an in-process database), SQL Server (now with LocalDb for in-process support), or VistaDB (proprietary, but 100% Managed code). Note that Access also supports acting as a front-end for a SQL Server "backend" data-store - where you could create a VIEW that performs this operation, then query the view from your Access code or other consuming client.
There is a workaround if you must: Create a duplicate column that contains the string-reversed value of your original column, then you can evaluate the ODBC LOCATE or JET SQL InStr functions on it and get the result you want (albiet, reversed) - but this would require double the storage space.
e.g.
RowId, FileName , FileNameRev
1 , 'Foo.txt', 'txt.ooF'
2 , 'Bar.txt', 'txt.raB'
Avoid any calculated field. It's a "super user" feature only, that will cause you nothing but trouble. Calculated fields - or expressions - belong in a query.
So create a simple select query:
Select
*,
InStrRev([FieldToCheck], "YourMatchingString") As StringMatch
From
YourTable
Save the query, and then use this whenever you need the table values and this expression.
good day, i would like to ask if it is possible to update a specific cell in ms access using visual basic. If it is possible, may i ask what would be the syntax to be used? Thanks!
Yes, it is possible.
The syntax would simply be an Update Query.
When you say "..using visual basic". I am interpreting that as using Visual Basic for Applications. Am I correct?
You can either create the query using QBE, and pass in the parameters in the Criteria field within the query.
You could then run the query via code:
DoCmd.OpenQuery "YourQueryName"
MS Reference
If that's not your preferred way, you need to look into constructing SQL strings into VBA.
Check out this StackOverflow question. String concatenation in VBA is different than just writing SQL in Access.
Hope this helps.
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.
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'