• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2693
  • Last Modified:

Peoplecode CreateRecord() ignoring a field ?

I am using the following code...

&FILE = "E:\PIGCODE\DATA\" | PW_BDGT_AET.FILENAME;

&MYFILE = GetFile(&FILE, "U", %FilePath_Absolute);

&REC = CreateRecord(Record.PW_BDGT_TMP);

&SQL = CreateSQL("%Insert(:1)");

If Not &MYFILE.IsOpen Then

 Error ("TEST: failed file open");

Else

 If Not &MYFILE.SetFileLayout(FileLayout.PW_BDGT_TMP) Then

 Error ("TEST: failed SetFilelayout");

 Else

 &FRS = &MYFILE.ReadRowset();

 While &FRS <> Null

 &FRS.GetRow(1).PW_BDGT_TMP.CopyFieldsTo(&REC);

 &SQL.execute(&REC);

 &FRS = &MYFILE.ReadRowset();

 End-While;

 End-If;

 &MYFILE.Close();

End-If;

Open in new window


The resulting error is a SQL error...


SQL error. Function: SQL.Execute

 Error Position: 0

 Return: 8604 - [Microsoft][SQL Native Client]Invalid character value for cast specification (SQLSTATE 22005) 0

 Statement: INSERT INTO PS_PW_BDGT_TMP (BUSINESS_UNIT,ACCOUNT,DEPTID,PRODUCT,LINE_DESCR,MONETARY_AMOUNT) VALUES (:1,:2,:3,:4,:5,:6)

 Original Statement: %Insert(:1)



Here's the problem, the table PS_PW_BDGT_TMP has 7 fields in it's record definition, NOT 6.  This of course means that after the first field on the insert statement, all the field data types are off which cause the INSERT statement to fail.



Any thoughts or ideas ?  Thanks!



- Flynn
0
Flynnster
Asked:
Flynnster
  • 2
2 Solutions
 
simonpaul64Commented:
Check the definition of the file layout - there may be some difference there between the file layout definition and the record definition. If you created the filelayout based on an old version of the record (with 6 fields) you need to update the filelayout as PS won't do that for you.
0
 
FlynnsterAuthor Commented:
Hey Simon :)

Well, I just solved this dilemma.  The record and the file layout of the record were created relatively speaking at the same time and there was no difference between the two, to address your suggestion.

Someone over at IT-Toolbox suggested looping through the field names of the record object to see if it was actually the CreateRecord function that wasn't doing it's job.  Come to find out, it was pulling all seven fields as it should.  Then, I went and used pplcode to read each line of data into another file, to show me exactly what it was getting.  First thing I noticed, it was receiving all seven fields, so that was not the culprit.  What I did not was that the final and seventh field was a monetary field in nature, yet for any field value of zero, the accountants had it set to translate to a hyphen instead of a zero (WTF?).  I realized it was expecting a numeric value, not char, and that this could have caused the cast issue that SQL Server returned as an error.  So I quickly converted all seventh field hyphens to zeros, and VOILA, it worked!

Lesson Learned :  It's allways the end users who are at fault :)

- Flynn
0
 
simonpaul64Commented:
LOL - glad you found it!
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now