MSSQL Problem with Clarion 11.1 Re-build

questions
#1

Hi all,

After re-compiling 2 programs without changes from C11.0.0.1360 with C11.1.13744, which both use an MSSQL database (v15.0.2080.9) containing many tables I get Error (01S01) after opening one table only in exactly the same database, revert to the earlier C11.0 and no problems, all works fine.

The SQL profile (below) shows no error line.

Version: 11.1.13744
074CH(1) 14:02:30.373 SET_PROPERTY(dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.390 GET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.390 GET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.390 SEND(dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.398 OPEN(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.398 BUFFER(dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.398 BUFFER(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.398 SET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.398 SET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.398 SETview(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:30.400 PREVIOUS(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:33.840 SET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:33.840 SET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:33.840 SETview(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:33.840 NEXT(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:36.574 SET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:36.574 SET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:36.574 SETview(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:36.574 NEXT(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:37.667 SEND(dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:37.667 CLOSE(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:37.667 GET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs
074CH(1) 14:02:37.667 GET_PROPERTY(VIEW:CA2920:dbo.ArchiveWard:0CA1924H) Time Taken:0.00 secs

All other tables work fine, and this has no obvious significant difference to any others in indexes, datatypes etc.

Is anyone else seeing similar? The error message is a rather unspecific one so not helping me much either.

Regards, Jim

#2

Any difference in how the FILE declarations are generated between the 2 versions?
What’s that exact error?
Is it listed in the help under “Extended ERRORCODE 47 Errors”?
Have you compared the Clarion FILE declaration to the definition of the SQL table? Any Clarion reserved words in the labels?

#3

Hi,

This is what baffles me. Everything matches exactly in the program codes. In one program, because it is automated in use, every operation apart from opening and closing can record ERRORS or FILEERRORS in their logs, and no other error is recorded in the log. Other tables open and process then close, all without error. This happens on Open, before any processing. No other messages show on screen through the ABC methods. Nor can I see anything in the SQL profile. Just this one, on screen via the ABC internals, which comes on opening, before any record retrieval is tried. All other tables in the database (and there are many) seem fine too. That would suggest it’s the SQL side but why does the C11.0 program not have the issue? Using SQL Server studio on that table, I can return queries without any problem, so is it the SQL?

In view of time pressures I have gone back to the C11.0 environment. I can’t use C11.1 for other programs that provide reports because of the report problem described in another thread, so for me, this is manageable. I would like to get to C11.1 eventually though.

Regards, Jim