views:

263

answers:

3

Access 2007 databases querying linked oracle 10g tables are returning flawed result sets when using the WHERE clause to filter-out unwanted records. Oddly, some filtering is happening, but not reliably.

I can reliably demonstrate/produce the problem like this:

  1. Create a *new* database with Access 2007.
  2. Create a second *new* database with Access 2007, and then "save-as" 2000.
  3. Create a third *new* database with an older version of Access.
  4. Run the following query in each database:
SELECT 
    STATUS, 
    ID, 
    LAST_NAME, 
    FIRST_NAME
FROM 
    Oracle10g_table
WHERE 
        STATUS="A" 
  • In both databases created with Access 2007, running this query will give you a result set in which some of the records where (STATUS="A") = false have been filtered out, but not all of them.
  • In databases created with older versions of access, the where clause filters properly, and the result set is correct.
  • STATUS is a text field
  • The table is a "linked" table to an Oracle10g Database
  • The table has 68k rows
  • I've tested my timeout at 60, 1000 and 0

Has anyone run into this problem?

I wonder if this is a new "feature" of access that will also affect 2010. Could this have anything to do with ODBC?

Thanks for any help, - dave

MORE...

I just tried an alternate form of the query, using HAVING instead of WHERE, and it worked! Problem is, besides that this shouldn't change anything (yes -- more virtual tables, but shouldn't change the end result) my end-users will be using the Access 2007 visual query designer, not typing SQL directly, which is going to default any criteria they enter into a WHERE.

+1  A: 

My hunch is that one of your ODBC drivers used by Access to connect to Oracle is treating "A" as a column name not the literal 'A'. Have you tried single quotes on the 'A'? In Oracle double quotes are used to reference column names, is there a column named "A" by any chance?

Oracle Query Example #1

Select object_name from all_objects
where "OBJECT_NAME" = 'DUAL'

Oracle Query Example #2

with example as (
Select object_name as "Fancy Column Name" from all_objects
)
select * from example
where "Fancy Column Name" = 'DUAL'
Brian
Thanks Brian. Actually, since ODBC is translating between Access and Oracle, this isn't the issue. I checked it anyway, since I'm at that 'i'll try anything' stage of troubleshooting :-), but yeah, no joy.
dave
A: 

This turned-out to be an ODBC-related issue. Our tech support service unit installs connectivity on each of our workstations -- they program it themselves, and who knows what they actually put into it -- but the net result is that when you link to an ODBC datasource with Access (of any version), our network servers show-up in the 'machine data source' tab, so we just click on the one we want and away we go. This has worked well until Access 2007.

What I did was create a "new" machine data source, which let me choose the ODBC driver myself (instead of making me use the one our tech support folks created). I picked "Microsoft ODBC for Oracle", entered the name of the server I wanted, and that all it took. Now the WHERE-clause inconsistent filtering problem is solved (I hope).

The only thing remaining is to send this back to our tech support folks, so they can clean-up their installation. Should I ask for hazard pay? :-) hehe

dave
Actually, we have great tech support. I feel it's my solemn duty to give them a lot of guff from time to time. But in all honesty, what they do for us is still "magic" in terms of my ability to understand it; they work hard -- gotta give 'em that. Hasn't helped any that they've lost so many positions to layoffs thanks to the bad economy / budget crisis that we're in.
dave
Two things: you should consider DSN-less connections (http://www.accessmvp.com/djsteele/DSNLessLinks.html), and any time you have wonky results from an ODBC linked table, delete the linked table and recreate it. ODBC linked tables cache metadata that is almost never properly refreshable, so you have to create an entirely new linked table.
David-W-Fenton
Good advice -- thank you.
dave
Interestingly, the problem with the old ODBC connection was related to Access asking you which field you want to identify as the primary key field when you link to the table. Of course, no typical end-user would have any way to know what to choose (100's of tables in the list, with no indication of key fields). In 2003, the choice doesn't matter. But in 2007, if you choose a field that has nulls in it, that's when the WHERE clause started malfunctining. So, two ways to overcome: 1) change the odbc to Microsoft's ODBC for Oracle option, or else pick a pk field that has no nulls in it.
dave
That's exactly the kind of thing deleting and recreating the linked tables corrects.
David-W-Fenton
Yeah -- I get it, and that works well for a lot of problems -- but in this case, since Access 2007 was taking issue with the nulls in the column the user chose, re-linking didn't help. If we re-linked to a better field, the problem would (appear to) go away, but that was a bit of a hack that left us less-than-confident, as the real problem was with the ODBC driver itself not getting along with Access 2007 or later (we verified this was also a problem with 2010). DSN-less connections were a good idea too, but not an option for my users, unfortunately.
dave
I didn't mean relink at runtime, but relinking before releasing into production use. In addition, tables without a PK designated in the schema indicate a really bad table design. ODBC should never have to ask -- it should be able to tell what the PK is from the table's metadata. If it can't, that suggests bad design to me. I recognize that you may have no control over that, unfortunately.
David-W-Fenton
I don't understand how a DNS-less connection could not be an option.
David-W-Fenton
Yes Dave -- relink at design time doesn't solve the problem. It's an Access 2007 problem with the ODBC connection. I promise. :-) Also -- I don't control the environment 100%. The tables are created by a product our instution bought -- not me. Bad design maybe, but nothing I can do about it. DSN-less connection not an option because I'm not the one who does all of my users' table linking -- they do it themselves. Access is used as a 'ad hoc' query/reporting solution, not an application in and of itself. We use more serious stuff for our regular apps.
dave
+1  A: 

I've had a similar problem. In my case, changing the ODBC driver worked, but I could also just change the 'unique record identifier' to a column with no nulls in it. It still doesn't have to be the "right" unique record identifier.

That seems to work. I think it's a bit of a hack -- it doesn't explain why 2003 and 2007 behave differently. But it's something I can use until our tech support folks get the ODBC figured out. Thanks!
dave