forum.connectivity (1998-2005) & forum.td.connectivity (2005-2010)
Posted by: Shawn Muller
When we upgraded to 3.1, we sometimes got the error
SQL Error 202 Not a SELECT command when loading table windows. This
happened when connecting to oracle. What we did then was take the
SQLORA32.DLL from centura 1.1 and everything worked fine.
We are now upgrading to Team Developer 5.1 and the error is back
Oracle client is 9.2, Server is 9.2
Team Dev. is 5.1 SP 2
Any ideas what this could be?
- Site Admin
- Posts: 2172
- Joined: 04 Mar 2017, 18:34
- Location: Palm Springs, California
Posted by: Jeff Luther
Couple possible clues in your msg. and in the full description for 202:
"Reason: Trying to fetch or position within a result set when the SQL
statement is not a SELECT."
Here's what comes to mind; could be any/one/all of these; these are what I'd
-- Your hSql SELECT handle is being reused after a SalTblPopulate() call (I
assume that's how you are pop'ing the TW.)
-- But... table window doesn't have cache = no (and a large max rows value)
set and the user is trying to scroll. For this, hSql handle has to still
have the SELECT cmd. on it, but doesn't and the TW can't fetch any more rows
-- default result set mode = TRUE for SQLBase, I don't recall for Oracle but
possible you don't have result set mode turned on (?)
-- Still using the "centura 1.1" DLL?? I can't imagine that would still be
valid with 5.1 - though sounds like your problem isn't in the router, but in
the TW, cache, not having a compiled SELECT cmd. for your hSql and your code
reusing that handle.
-- Is the 202 exactly when "loading table windows"? or after the TW is
populated and the user, for example, makes a change and click an Update DB
menu or similar? If so, what's the hSql handle used for the DML
(insert,update,delete)? Same as the TW pop. handle?
- Jeff/Unify Corp.
Posted by: Shawn Muller
Thanks for the answer. We have a class where we first prepare the select
statement. So For example we would First do a SQLExecute. If there is an
error (SQlExecute returns FALSE), we doa SqlPrepareAndExecute and
everything is OK. This was the behaviour with the older sqlora. Since 3.1,
SqlExecute returns TRUE in this case which means we don't do the prepare and
Posted by: Jim McNamara
This error is the result of a trying to use a cursor after a commit has been
call or after a cursor has been repositioned. To overcome this you need to
call SqlSetParameter ( hSql, DBP_Preserve, TRUE, '') right after you
connect the sql handle.
Who is online
Users browsing this forum: [Ccbot] and 42 guests