This code serves no purpose, and you should remove it. It’s not the root of your problem, but it’s just extra work that will make things worse, not better.
The root of your problem is that you are using MESSAGE for debugging. Specifically in this case, using <10> as a line separator. You probably want to drop that, or replace with <13,10>.
Also, you don’t actually say what you are seeing, so it’s tricky to see beyond that.
Thanks for that. The fetch went in as an attempt to sort the problem. The issue is that although it finds the relevant records the only fields that seems to be available to me is the Item field which is the first field. I need to assign the second field to a field in the queue but it always returns as blank.
Set:Item would apparently be set to something, because it’s getting past the CYCLE statement.
if IQ:ItemQueue is always blank then it’s likely because Set:Item[16:50] is blank.
Hi Bruce. Set:Item is being read from the table. Once the loop finds a record that matches the criteria, I should be able to read all fields for that record shouldn’t I? Such as SET:Detail from the example. Despite there being data in the table all fields other than SET:Item are returning as blank. The same basic code is being used in other areas of the application and function correctly. For since reason it is not working correctly for this table.
Once the loop finds a record that matches the criteria, I should be able to read all fields for that record shouldn’t I?
no, only fields that are PROJECTed in the VIEW.
Despite there being data in the table all fields other than SET:Item are returning as blank.
In your example SET:ITEM and SET:DETAIL are in the View, so those are the only two you should access in your code. (If you want more fields, add more PROJECTs)
The same basic code is being used in other areas of the application and function correctly. For since reason it is not working correctly for this table.
The behaviour can be driver dependant. So, for example, the way a VIEW works on a TPS record is different to a MSSQL record. You should , in all cases, assume that fields not in the VIEW are not available. (If it works without that, against some driver now, it’s no guarantee it’ll work in the future.)
Right. I get that.
The only field available to me is the Item field which is the first field in the table. The Detail field returns as blank.
I have tried adding all fields to the view. All fields other than Item are still returning blank.
All tables in the dictionary use the same sql anywhere driver and connection string.
Is there perhaps something that needs to be set against the table in the dictionary?
Have you tried using ODBC Admin to log a trace file and see what actual SQL is being passed? Does the same select statement give the expected results outside of Clarion?
The application is running on the same database as my test database. It’s not using an odbc connection.
Good suggestion though. I may use it if I have issues on our live servers.
It is multi dll and I have tried compiling the whole solution however everything was already in there including the procedure I’m working on and the table called Settings.
I have only added the view on the settings table, the queue that I want to populate and the routine to populate the queue.
Please consider the environment before printing this email.
Notice: This e-mail together with any attachments is confidential, may be subject to legal privilege and may contain proprietary information, including information protected by copyright. If you are not the intended recipient, please do not copy, use or disclose this e-mail; please notify us immediately by return e-mail and then delete this e-mail.
OK. Your issue sure does sound like when I’ve had mismatched global DLL record structures. Such as when I changed the dictionary but didn’t compile all of the apps.