4 replies to this topic

[Mike Schoen]

We keep getting the error '368 - SQL ERROR: INVALID DATA TYPE FOR SQL' on an AIX installation running 4.6r216 and oracle 8.1.6.

This happens in an update which passes a transaction file and calls a global update to do record updates. We have some custom sql and pl/sql routines called in the global.

After the third iteration in the parent update, we get this
error and a rollback. Quitting out, and re-running the update then proceeds to correctly process the record that caused the rollback the first time.

The oracle trace log does not show any sql errors, this error gets generated by pro-iv.

Any ideas would be appreciated!

[Shaun Rudland]

G'Day Mike,

I remember a few years ago I had a similar problem with a function that would run correctly for a few iterations, and then produce some form of PRO-IV generated SQL error. If restarted, it would process the 'failed' transaction correctly. I finally worked out that it was due to numeric host variables within the SQL statements being corrupted by the execution of the statement. This may or may not have been calling procedures; my memory is hazy. The host variables were used within the statements, and within the PRO-IV code. The solution was to create another set of host variables, that were loaded before the SQL statement, and were only used within the SQL statement.

Just a thought.

Regards

Shaun

[Mike Schoen]

Thanks Shaun - while checking to see if I was using numerics I found the actual problem - I was using full function sql to select only the key field of the table, but telling pro-iv that it should expect the full file, ie all columns.

For some reason, solaris would let us get away with this, but the aix build would not...

[AlexKRE]

We keep getting the error '368 - SQL ERROR: INVALID DATA TYPE FOR SQL' on an AIX installation running 4.6r216 and oracle 8.1.6.

This happens in an update which passes a transaction file and calls a global update to do record updates. We have some custom sql and pl/sql routines called in the global.

After the third iteration in the parent update, we get this
error and a rollback. Quitting out, and re-running the update then proceeds to correctly process the record that caused the rollback the first time.

The oracle trace log does not show any sql errors, this error gets generated by pro-iv.

Any ideas would be appreciated!

For given trouble there is mdf recovery. It is able to work out trouble with corrupted or lost sql data. The software works under any Windows OS. It uses contemporary methods of restoring files from any SQL Server versions.

[Richard Bassett]

LOL @ idiotic spambot