Can ASP's objConn.execute handle a SQL query that uses the subquery factoring with clause?

Question

I have a long SQL statement that's essentially:

with a as (select * from t1),  
  b as (select * from a, t2 where a.id=t2.id)  
select * from b

This statement executes perfectly fine in my TOAD application. But, when I try to stuff the above into a string variable and run it in ASP using:

set rs = objConn.execute(strSQL)

I get the following error:
Microsoft OLE DB Provider for ODBC Drivers error '80040e37'
[Microsoft][ODBC driver for Oracle][Oracle]ORA-00942: table or view does not exist
/Application/xxxxx/yyyyy/myfilename.asp, line 168

Line 168 is the set rs = objConn.execute(strSQL) line.

I've used these same tables to run several other queries and posting them online using the set rs = objConn.execute(strSQL) line with no problem. The only thing I can determine is different with this SQL query is the subquery factoring.

I tried wrapping the whole query up in it's own select statement like:

select * from (with a as blah blah... entire original query)

But that still throws the same error. Can I just not use set

rs = objConn.execute(strSQL) 

in conjunction with subquery factoring? Is that not supported? Or is there some kind of work around? Or could it be something else entirely?

Thanks.

Answer 1

The Microsoft OLE DB Provider for ODBC Driver is very old. It was created when Oracle 7 was around and has not really been updated since. The WITH clause was added with Oracle 9.2.

I am surprised your select * from () workaround does not work. It is exactly what we are using and it is working fine for us.

Another solution is to use the Oracle Provider for OLE DB instead of the Microsoft driver. It is provided by Oracle and is updated with every Oracle release.

Answer 2

I'm stupid. Wrapping select * from () around the whole block does indeed work. My error was being thrown because I forgot I was trying to join into an old (rarely used anymore) table that was actually in a different schema that I wasn't connected to. I solved the problem by rewriting the query to pull some of the needed data from that obscure table to a different table that I was connected to and contained the same data I needed.