I am using MS Access 2010 to run queries on a SQL Server Database using an ODBC connection.
Whenever I convert the tables involved in my query to local tables, my query only works if my string wildcard is the ACCESS standard wildcard of the * character.
However, if my query involves so much as a single linked table from the SQL DB, I have to change the wildcard character to the SQL standard of the % character for the query to work.
Is this indeed the case? Is there anyway around this so that I don't need to remember the wildcard character depending on whether I have linked or local tables?
Is there anyway around this so that I don't need to remember the wildcard character depending on whether I have linked or local
tables?
Access SQL supports ALike as an alternative to Like. The difference with ALike is that it signals the Access db engine to always expect ANSI wildcards (% and _ instead of * and ?).
So SELECT * FROM Foo WHERE some_field ALike 'a%'; will always return the same rows ... regardless of the context where it is run ... as long as the Access db engine is handling it.
Related
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.
I'm trying to check the results of a data load between two databases. Unfortunately, I only have access to one database (MySQL) directly, the company managing MSSQL can expose it to us via an API.
What I would like to do is check the consistency of certain columns across rowsets. Originally, I had hoped to be able to run a CRC or hash check against the columns, but there doesn't seem to be a compatible way of doing this.
For example, we can run CRC32 against a column in MySQL, but there isn't a reliable way of doing the same on MSSQL. Alternatively, there's CHECKSUM_AGG on MSSQL, but no alternative on MySQL.
The end result is that I would like to do a binary search if the checksums differ to identify the rows that require changing.
There is currently no bulk load interface, and SSIS is not available (the MSSQL servers are not part of my company).
I thought I'd come back to this and describe the solution we ended up implementing. This was a major pain in the neck!
Firstly, because of the fixed versions of MySQL on our server and MSSQL on the remote server, there were no common encoding methods.
The MSSQL API returned data in UTF-16LE, the MySQL database had Unicode data stored in Latin-1 tables sigh
Firstly, we concatenated the fields that we were comparing, then we MD5'd the result. In order to get the MySQL result to match the output of the MSSQL HASHBYTES function, we had to do this:
SELECT ABS(CONV(CONCAT(
IF(MID(MD5(CONC), -8 , 1) >= "8", "FFFFFFFF", ""),
RIGHT(MD5(CONC), 8)
), 16, -10 )) AS CALC
where CONC is the result of a subselect concatenating the fields we are interested in.
On the MSSQL server, we had to do the following query:
SELECT ABS(CONVERT(INT,HASHBYTES('MD5',
CONVERT(NVARCHAR(4000), FIELD1 ) +
CONVERT(NVARCHAR(4000), FIELD2 ) + ...
Then, we took the sum of the MD5 across the entire range, modulo three large-ish primes(311,313,317), as per Chinese Remainder Theorem
This gave us three numbers for the range we were checking. We could be reasonably certain that if all three numbers matched for a given range on each server, then the data was consistent.
I'll spare you the details of the munging we had to do to get Unicode in Latin-1 transliterated to UTF-16LE
I am using Access(2003) mdb file as front end of oracle 11g R2 as backend. I am using odbc connection to retrieve data from oracle database. But sometime mdb is displaying incorrect output.
For example, when I use the below query in mdb
SELECT *
FROM PLAN
WHERE (((PLAN.BATCH_REF)="SSU080520122"));
and it is providing wrong result. But the same query is providing correct result in oracle.
Any help will be appreciated.
PLAN is a reserved word. Using reserved words as table or column names can confuse the db engine. Although this may not actually be the source of your trouble, it would be easy to rule it out as a contributor. See if you get the results you expect with this query:
SELECT *
FROM [PLAN] AS p
WHERE p.BATCH_REF="SSU080520122";
I want to store IP addresses (v4 and v6) in my rails application. I have installed an extension to MySQL adds functions to convert ip strings to binary which will allow me to query by IP range easily.
I can use unescaped sql statements for SELECT type queries, thats easy.
The hard part is that I also need a way to overwrite the way the field is escaped for insert/update statements.
This ActiveRecord statement
new_ip = Ip.new
new_ip.start = '1.2.3.4'
new_ip.save
Should generate the following SQL statement
INSERT INTO ips(start) VALUES(inet6_pton('1.2.3.4'));
Is there a way to do this? I tried many things, including overriding ActiveRecord::Base#arel_attributes_values, without luck : the generated sql is always converted to binary (if that matters, my column is a MySQL VARBINARY(16)).
ActiveRecord::Base.connection.execute("INSERT INTO ips(start) VALUES(inet6_pton('1.2.3.4'))")
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).