We found a workaround: The big SQL script is now saved into a database field and then executed by the exec()-function. The frontend only has to exec a SQL procedure that starts the exec()-function.

Besides, we found out that size restrictions of the SQL-script were not the reason of the problem. 

But we use a cursor construct within the SQL-script which contains very many SQL commands - probably this could be pitfall.

Thank you all for your valuable hints.

Peter

If I remember correctly (ie this may be wrong!) I had a similar problem using ODBC with MS SQL Server.

I'm pretty sure the answer for me turned out to be increasing the PBMaxTextSize setting in the PBODB190.INI file.

From the documentation in the INI file:

   ;PBMaxTextSize='32767' only used by MS SQLServer for Text fields limit

Hi Chris,

thanks for your question.

It's about pressure from my customers and the Microsoft announcement to not further develop the SNC.

Would you recommend otherwise?

Regards,

Peter

Hi Peter;

  My 1st BIG question ... why are you changing from SNC to ODBC (aka "middleware")?

Regards ... Chris

Hi,

I would first make sure that the parts which don't execute would work in a small script using ODBC:

Why not, just set tracing on in your sqlca.dbms parameter by preceding it with "TRACE ODBC" or "TRA ODBC". The output will then give you more clarity about why some of the commands did not run and if indeed it's a size problem.

ODBC is a lot more limited than any native driver, especially when it comes to 'execute dynamic' commands.
Once you are sure that indeed it's to do with the size of the script, you could split the script into several ones instead of one big one. (but I don't think that's really the problem here).

regards.