WRITE statement - How the aphanumeric value is mapped to numeric field

Author: jayesh.g.patel@accenture.com (Jayesh82mscit)

Hi All, In the recent time, we faced the problem in which while writing the data into database through WRITE statement, value part was behaving differently. Let me try to explain with little mockup TABLE- PolicyMaster (having 258 fields/columns) SCORE_STEP_UP (Field sequence# 254)  - Numeric field with 3 digit length CREATED_BY (Field sequence# 255) - Varchar field with 15 chars length While making a change to Uniface MODEL for one of the another entity (lets say Table#2), unknowingly the sequences of above fields (from table -PolicyMaster) got swapped. We do use the Subversion for source control though not sure if any ways to control to prevent this in future. However while navigating the application, some of the users, system was performing well but for some it wasn't. When observed the patterns and logs, it was concluded that the userid value is mapped to field called SCORE_STEP_UP instead of CREATED_BY and then while hitting to WRITE statement, Uniface was throwing $status -6 Error (Conversion error). Here is the example userids - WRITE statement worked fine (based on the pattern observed) ABCD123 A11111A 123ABCD 111A2222 1111A222 Here is the example userids - WRITE statement failed (based on the pattern observed) A12346 12345A 1234 4321E etc. My query is what is the logic to assign the value our of the above sample user ids into SCORE_STEP_UP field while updating the data into DB (through WRITE statement) specially when this field is NUMERIC field ? I am unable to find further tracing/logs post the WRITE statement in Uniface. Appreciate response or more guidance on this problem. Regards, Jayesh

6 Comments

  1. Hi Jayesh, 1st - what is the dbms you're using? 2nd - are you using any of the Uniface generated stored packages / procedures for I/O? 3rd - did you recompile ALL objects in Uniface where this entity is used? Strictly speaking, unless you're using a record management system (CISAM or RMS for example), (or SEQ / TXT as well), as far as I know, the sequence of the fields should not matter. Regards, Knut


    Author: Knut (knut.dybendahl@gmail.com)
  2. 4rd – Did all users leave the application and restarted the application after deployment of the new components (assuming step 3 was done)?          (otherwise the user who stayed 'in' could be still using some old components from memory, containing the old model/entity/field definitions, while others use the 'fresh' model/entity/field definitions).


    Author: Arjen van Vliet (arjen.van.vliet@uniface.com)
  3. Hi Jayesh To check what's going on, one can use $ioprint=191 Uniface will not even show you the calls to the database driver but also the data it's send. Okay, the format is hex and a little bit cryptic, but you find (almost) all information you need BTW: The first component, that's oen a connection to a table will set the structure of the buffer. So look for the first occurrence of the table in question and check, if that are the fields you read/write to database. If this field are in another sequence (compared to the model, not to database) or the types are differnt, then you got the source of the problem Wink Ingo


    Author: istiller (i2stiller@gmx.de)
  4. Knut said Hi Jayesh, 1st - what is the dbms you're using? 2nd - are you using any of the Uniface generated stored packages / procedures for I/O? 3rd - did you recompile ALL objects in Uniface where this entity is used? Strictly speaking, unless you're using a record management system (CISAM or RMS for example), (or SEQ / TXT as well), as far as I know, the sequence of the fields should not matter. Regards, Knut  

    Thanks Knut for your response. Here is the information what is needed. 1st - what is the dbms you're using?  <JP> Its AS400 DB2 database (for transaction data storage) 2nd - are you using any of the Uniface generated stored packages / procedures for I/O? <JP> No, we don't use any of Uniface generated stored packages / procedures for I/O. 3rd - did you recompile ALL objects in Uniface where this entity is used? <JP> Yes, there was a full compilation of the latest changes before validating/testig through application 4rd – Did all users leave the application and restarted the application after deployment of the new components (assuming step 3 was done)? <JP> Yes, I believe users are forced to re-login to application (its web based application) as the application server itself is restarted after the Uniface code deployment. Additionally I would like add that we are using XML DTD structure for data movement to any of the entities. Awaiting for your response. :) Thanks in advance. Jayesh


    Author: Jayesh82mscit (jayesh.g.patel@accenture.com)
  5. Hi, You say you did a "full compilation of the latest changes". But maybe the entity is also painted on other components that you did not change. These components need to be compiled as well. If you need help finding the components you can try this: http://theunifaceuniverse.blogspot.nl/2011/04/change-entity-compile-forms.html Regards, Theo Neeskens


    Author: Theo Neeskens (tneeskens@itblockz.nl)
  6. Hi Jayesh, is your application using subtypes of the changed entity? Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)