I'm getting a "W3612 : Error running SQL: CommandText does not return a result set" error when running a dynamic SQL statement that is using the UPDATE command. I believe this is because the plugin is expecting data returned (obviously ) and that it can be safely ignored. The SQL UPDATE command executes properly, but generates the error in the log. It will also cause a subprocess to report it has failed if it contains the db plugin.

Would it be possible to turn off the "expect result" behavior if the plugin is using dynamic SQL at runtime?

I can see how, in normal operation, the result set error would be useful, but when switching to dynamic sql the error makes debugging more confusing.

Thanks,
-nth-

Sounds like a reasonable (and practical) request.
We'll add it to our request database.

Hi, If this change is implemented is it possible to receive an email.

Our process had a lot of Write and Update to do.
we also had this error message so since it always reported an error we had to replace all database connection by a Perl script.

I'm sorry, we can't send emails out to everyone making requests when things change in the applications. But the Release Notes will reflect thos improvements and they are always made available before you download a version, so you'll know exactly if/when the feature becomes available.

Ok thanks

Is it possible to post the change back to this thread?

If a person wants to be notified they can reply to the thread, but select the "Full Reply Form". They they will have the option to select "Email Notification" when ever someone replies.

This specific issue has been fixed in V7.1: when selecting a Dynamic SQL query, you can now specify that the statement should not expect a RecordSet to be returned. No error is raised when that occurs, and the same data file that came into the task remains the data file for the following task in the process.

Uomo: unfortunately, there are so many posts here that it's virtually impossible to associate each of them with a possible feature request or issue fix. Furthermore, we do not publish a comprehensive list of all fixes that were implemented into the software (for instance, V7.1 contains more than 60 new features and over 140 fixes!) so I guess you'll have to experiment with the new version by yourself to find out.

But I'll keep in mind the suggestion of publishing a detailed log of every issue/feature in each new release, as it would certainly prove helpful when we release feature-packed versions like V7.1.

I like the idea of a detailed log of features/fixes/issues. Perhaps with a query feature if it's web based.