× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well it has severed them well since all support for NT looks like it ended
about 2004. I don't want to even imagine what the HW it's running on.

I think *if it is possible* to take the SQL statement(s) to another box
running a current OS and run it from there might give some insight...

On Thu, Nov 8, 2012 at 6:42 PM, Pete Helgren <pete@xxxxxxxxxx> wrote:

Getting that 7.1 IBM i Access release for Windows NT has been a
bear....if you find it let me know :-)

(Client side is Windows NT....)

Pete Helgren
Value Added Software, Inc
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 11/8/2012 7:03 PM, Kirk Goins wrote:
My first step with any ODBC error after an OS Upgrade is to Upgrade the
Client Access ( with Service Pack ) on the devices having the ODBC issue.
Then and only do I proceed with any T/S

On Thu, Nov 8, 2012 at 3:06 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

The change from a literal specification to a parameter marker is
called "parameter marker conversion". IIRC there is a setting in the
INI, but that query option is likely not an issue, unless perhaps the
setting has changed.

The issue might be related to the SQL Package that stores the
statement. Many people will blindly delete packages to avoid any
"weirdness" similar to what they had seen in prior release upgrades. I
would always save before any deletions, to avoid losing information to
debug\review the failure, for example if the deletions resolved the
issue. I had read once that changing the driver to stop using packages
turns off Extended Dynamic support.... but I only ever dabbled in any
client stuff, mostly only ever dealing with the server side. I would
think that the system-wide cache might replace packages for the extended
dynamic, though perhaps not.

--
Regards, Chuck

On 08 Nov 2012 10:00, Pete Helgren wrote:
A little more information now that I have used DBMON and done some
more research....

I thought it was fixed but customer reports this is still an issue.
Environment is a Windows NT box running an IVR app that uses an ODBC
interface to I/O to DB2 on i. App has been working flawlessly since
1996 (yeah, really).

It appears that the i isn't happy with this SQL statement:

UPDATE PASA408 SET ABSDSB = ? WHERE ABSID = ? AND ABSDSB = ?

The *actual* SQL statement that is submitted from the IVR is this:

update pasa408 set absdsb = 0 where absid = ? and absdsb = ?

So I am not sure how the absdsb = 0 gets translated to ABSDSB = ?
(guess that the db2 for i database does some optimization). DBMON
reports SQLSTATE 42612 with SQLCODE -84. The Hit ODBC driver returns
this to the IVR status screen:

>> SQLExecDirect fail : -1
index --> 0, hstindex --> 7
SQLState : HY000
NativeError :
?
ErrorMsg : [HiT][HiT ODBC/400][SQL/400][ODBS Error]SQL statement not
allowed.

So I am not sure where to go with this. Apparently this kind of
statement is no longer allowed (seems benign enough). The purpose of
the SQL statement is to set the value of absdsb back to zero. I have
a limited bag of tricks in this particular IVR environment. Not a lot
of SQL options but I am willing to try...

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.