I am trying to run the following query:
SELECT Project.* FROM Project WHERE (((Projects.[End Date (PPL)])>=DateAdd('m',-6,Date())));
It runs fine in Access (2007) however when i move it over to VBA:
strQry = "SELECT Project.* FROM Project WHERE (((Projects.[End Date (PPL)])>=DateAdd('m',-6,Date())));"
I get an error message saying 'No value given for one or more required parameters'
I can get it running with the following code but it doesn't provide the correct information:
strQry = "SELECT Project.* FROM Project WHERE Project.[End Date (PPL)] >= DateAdd('m',-6,Date());"
Any help would be great.
The definitive answer to your question is here, in StackOverflow:
VBA function in Excel ADODB query
The short answer is:
You're using a dialect of SQL called Jet-SQL, and most people call it from Microsoft Access, a database application which makes VBA functions available to the SQL engine.
If you run Jet SQL from any other platform - like an ODBC or ADODB wrapper -the VBA functions aren't available: all you have is the Jet-SQL native functions.
There's a list of the native Jet-SQL functions here: it's almost complete, and you can see that it's rather short:
MS Access: Functions - Listed by Category
...And it doesn't include NZ()
It's somewhat confusing that these functions look like the familiar VBA - and annoying that the web page listing them is labelled 'MS-Access' rather than Jet SQL.
There is an interesting item in that list: the inline 'If' function, IIF(), and you can use it as a substitute for NZ:
SELECT
IIF(
table1.[RIC] IS NOT NULL,
table1.[RIC],
table2.[ISIN] + ', CODE:ISIN'
) AS [RetrievalCode],
table3.[Value],
table3.[DateStamp]
FROM
* The rest of your Query *
Hope that helps: I suspect that it won't, because you may be calling a named query (or SQL with a named subquery in it), and all the non-native function calls in those queries are invalid unless the whole thing is called from within MS-Access.
You can, of course, make a 'schema' query and extract the SQL, parse it out, and replace all the VBA with native Jet-SQL functions. But the syntax for Jet-SQL gets arcane when you're outside it's intended environment - the Query-By-Example visual query builder inside Microsoft Access - so that suggestion may be more time and trouble than doing it some other way.
Related
I hope someone can shed some light on this strange behavior.
I have a very simple sql statement thus:
"SELECT TOP 1 PartRefID FROM Parts WHERE PartDescription LIKE '*Backshell*' AND ParentID = 2097"
which is executed scalar.
when I enter this in the access query editor it works just fine and returns the expected value.
however, when I run it from within some vb.net code it always returns zero.
can anyone tell me why this is the case?
thanks
When using .net, you have to use the % sign - it more of a ANSI standard, and this works with jet/ace (access) data engine also.
So, when writing .net code as opposed to VBA, then you are to use % for wild cards - not *. In fact, even in Access VBA, if you were to use ADO (as opposed to the more common and recommended DAO - then even in VBA + ADO, you have to use % in place of *).
so in fact most sql syntax uses %. For ADO, or now what is called ado.net? Then % is to be used.
However, inside access? You can turn on ANSI compatibility - but it WILL make a huge mess of existing access applications - so I don't recommend doing this (enabling Access ANSI sql compatibility mode).
You can quite much assume for "most" software outside of Access - EVEN when hitting the Access database, you use % for wild cards. The only exception here is if one was to use DAO directly as a reference library, and I STRONG recommend you don't do this.
so try using % - and all should be find and well.
Try to replace *
"SELECT TOP 1 PartRefID FROM Parts WHERE PartDescription LIKE '%Backshell%' AND ParentID = 2097"
I'm trying the following query from the BigQuery Standard SQL documentation:
SELECT DATE_DIFF(DATE '2010-07-07', DATE '2008-12-25', DAY) as days_diff;
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#date_diff
However, I'm receiving the following error from the UI:
Error: Encountered " "\'2010-07-07\' "" at line 1, column 23. Was expecting: ")" ... [Try using standard SQL (https://cloud.google.com/bigquery/docs/reference/standard-sql/enabling-standard-sql)]
This is a simple copy and paste from the doc into the web UI Query Editor.
Any idea on how to resolve this?
Below are examples for respectively BigQuery Legacy SQL and Standard SQL
Make sure you try code as it is in answer below - not just second lines but 2(both) lines including first line that looks like comment - but in reality important part of query as it controls which SQL dialect will be in effect!
#legacySQL
SELECT DATEDIFF(DATE('2010-07-07'), DATE('2008-12-25')) AS days_diff
and
#standardSQL
SELECT DATE_DIFF(DATE '2010-07-07', DATE '2008-12-25', DAY) AS days_diff
both returns result as below
Row days_diff
1 559
Ideally, you should consider migrating to Standard SQL
Although the answer has already been provided in the comments to your questions and by Mikhail in the other answer, let me share with you a complete answer that hopefully addresses all your doubts:
ERROR MESSAGE
As explained in the error message you are getting, [Try using standard SQL (...)]. You are trying to run this sample using Legacy SQL (which instead would use the DATEDIFF function). You are actually right, you are running the exact same query provided in the documentation, but the issue here is that the documentation you are using is for Standard SQL (the preferred query language in BigQuery), but you are instead using Legacy SQL (the default language in the old UI, the one you are using).
CHANGE THE QUERY LANGUAGE IN USE
First of all, I would like to remark the importance of using Standard SQL instead of Legacy SQL, as the former adds new functionalities and is the current recommended language to use with BigQuery. You can see the whole list of comparisons in the documentation, but if you are starting with BigQuery, I would just go straight away with Standard SQL.
Now, that being clarified, in order to use Standard SQL instead of Legacy SQL, you can have a look at the documentation here, but let me summarize the available options for you:
In the BigQuery UI, you can toggle the Use legacy SQL option inside
the Show options menu. If this option is marked, you will be using
Legacy SQL; and if it is not, you will be using Standard SQL.
You can use a prefix in your query, like #standardSQL or #legacySQL, which would ignore the default configuration and use the language you specify with this option. As an example on how to use it, please have a look at the other answer by Mikhail, who shared with you a couple of examples using prefixes to identify the language in use. You should copy the complete query (including the prefix) in the UI, and you will see that it works successfully.
Finally, as suggested by Elliott, you can use the new UI, which has just recently released in Beta access. You can access it through this link https://console.cloud.google.com/bigquery instead of the old link https://bigquery.cloud.google.com that you were using until now. You can find more information about the new BigQuery Web UI in this other linked page too.
Ok, this may be a long shot but in MS Access, is it possible to execute VBA using SQL? I'm looking to write a query that runs either a single VBA statement or a Sub. Basically, what I'm trying to do is modify the hidden attribute of a table using SQL.
MS makes enough weird decisions with Office implementations that I'm mildly hopeful this is one of those cases.
You can create a VBA function and use the function's return value as a field expression in a query. However, you must run the query from within an Access application session. Otherwise the db engine will not be able to use your custom function.
SELECT YourFunction() AS result;
It's been a few years (thankfully) since I used Access, but to the best of my knowledge, that's simply not possible. You can use VBA to execute SQL, but not vice versa.
You can use user-defined functions within an SQL query ( http://www.sqlexamples.info/SQL/inlineudf.htm ). I doubt Excel checks what you do inside this function, so you probably can do whatever you like.
I have a simple query but am running into problems using LIKE in VBA. My SQL string in VBA is:
stsql1 = "Select Top 25 data.* from data where data.Description Like ('*') "
When I run this sql string in my VBA code I get no records returned, but if I copy/paste the same string into a query in SQL View in MS Access, the query returns the values I expect. Is there a trick to using the "Like" syntax in VBA?
I can provide additional code and a small version of the database if that would help.
For SQL, the database engine will accept either single or double quotes as text delimiters. So either of these 2 WHERE clauses will work.
WHERE some_field Like '*'
WHERE some_field Like "*"
VBA however only accepts double quotes as text delimiters, so you would have to use the second form.
Two other points about your SELECT statement:
Select Top 25 data.* from data where data.Description Like ('*')
TOP [number] is arbitrary without an ORDER BY clause
You don't need parentheses surrounding your Like pattern ... you can use Like "*"
If your VBA code is using ADO with that SELECT statement, you must change the wild card character from * to % ...
WHERE data.Description Like '%'
In ADO/VBA, you have to use % instead of * as the wildcard. I ran into this a couple times in the past ....
Realize that there are at least 2 (yes two!) LIKE operators here.
One is the LIKE operator of VBA.
The other is the LIKE operator of the SQL of the database you are attached to.
The usual wildcards in SQL are % (for any # of any characters) and _ (for one of any character).
Know also that MS Access can open databases that aren't Access; it could be Microsoft SQL Server, or Oracle or IBM DB2. (BTW, the database that is normal for Access is called Microsoft JET.) You may be sheltered from that truth when you create a Query object in Access - in that circumstance, you are using JET SQL even when it's a linked table you are querying.
However, under VBA, when using either DAO or ADO, you're talking directly to whatever the database system happens to be, in which case you MUST use the SQL of that specific system.
OK, short answer: Use % like cularis said.
I can't add a comment, but I think it would be worth noting that you have to use % even if you are querying MS Access.
(example: Outlook VBA runs query on an Access database. The proper query is select * where user like '%bob%', even though this query would not work if plugged directly into an MS Access query).
I'm working on a legacy product and i have some SQL being executed through ADO, to an Access database with linked tables to SQL Server. I'm getting the error 'Undefined function 'Round' when i execute the SQL but if i take the query and run directly in Access it works fine. I know that EVERYTHING is correct and that this is a machine specific issue since this is production code, it works on other machines and has been deployed successfully for many clients.
I'm not even sure where to begin to be honest. I'm running the correct (latest) versions of Jet/ADO/MDAC.
ANY help would be appreciated.
Thanks in advance.
EDIT: Obviously, the SQL includes the aggregate function 'Round'. I'm aware of the differences between Jet and SQL implementations. This problem is due to some problem with a component on my machine and NOT with the code. The SQL executes properly when done through MS Access 2007 but NOT through ADO.
EDIT2: Right solution from the comments:
shahkalpesh: If it executes fine thru Access, it could be that Access has the DLL available to it, which has the Round function. What is the connection string, you are using?
Stimul8d: I'm not sure how it can be anything so do with the connection string. This code works on EVERY other machine, with no changes; just not on mine.
Andomar: Well, that's your problem right there, your machine is farked up. You can still install vb6 sp6 maybe.
Stimul8d: Well, SP6 fixed it. Cheers Anndomar, no idea why SP6 fixed it but it did!
EDIT: Based on your comment this newsgroup post might be the answer:
Unfortunately, when you are running
queries from outside of Access (as you
are from VB), your only connection to
the database is through the Jet
engine, which doesn't know anything
about most VBA functions. There's no
way around this, other than to return
the data to your VB application and
use the functions on the data there.
And two posts later:
I solved the problem. Updated my VB
with the Service Pack 6... it took
care of the problems.
Old answer here:
Try FLOOR() instead of ROUND().
To round something to the nearest integer, you could:
declare #floatmyboat float
set #floatmyboat = 1.51
select floor(#floatmyboat+0.5)
P.S. Maybe post the exact error you get. If it's "The round function requires 2 to 3 arguments.", that means Sql Server is borking on the ROUND().
The round() function exists in SQL Server as well.
The only difference is: in Access the precision is an optional parameter, but in SQL Server you have to specify it.
So this will only work in Access, but not in SQL Server:
select round(Column) from Table
This will work in Access and SQL Server:
select round(Column,1) from Table
it could be that Access has the DLL
available to it, which has the Round
function
ACE/Jet uses share expression services with VBA. Broadly speaking, ACE/Jet supports as expressions all VBA5 functions (as distinct from methods) whose arguments and return values are scalar types (e.g. no arrays, no objects). The Round() expression falls into this definition and indeed is available to ACE/Jet with the same semantics as its VBA function equivalent. As anyone familiar with the ACE/Jet engine should know, though, the semantics can differ from the VBA equivalents e.g. ACE/Jet ANSI-92 Query Mode SQL
SELECT TYPENAME(ROUND(5, 1))
returns 'Long', whereas VBA
?Typename(Round(5, 1))
returns 'Integer'.
In other words, Round() wasn't going to be the problem here.