search

cooperl22 / laravel-db2

laravel-db2 is a simple DB2 service provider for Laravel. It provides DB2 Connection by extending the Illuminate Database component of the laravel framework.
Other
59 stars 65 forks source link

Updated table structure ignored by Laravel #11

Closed sarahkemp closed 5 years ago

sarahkemp commented 8 years ago

I have been using this plugin to access data from an iSeries via ODBC. Yesterday, a column was added to the table my Eloquent model is associated with. Today, my data is coming in jumbled and the new column isn't showing in the model's attributes.

There are two new columns 'IVTYPE' and 'IVDOMI', which are not showing up in my dump of the model:

InventoryItem {#337 ▼
  #attributes: array:55 [▼
  ...
    "IVFIN" => "A"
    "IVUOM" => "D "
  ...
 ]

When I view the contents of the table directly, the IVFIN is 'B' and the IVUOM is 'CP', but the newly added columns (which are not showing in my attribute list) have 'AT' and 'D', respectively. To me, it looks like the data scooted over to fit the new columns, and the Eloquent model is somehow working positionally and thinks the columns haven't moved.

I ran artisan cache:clear but the problem persists. Is there something I need to do to trigger Laravel to notice the updated table structure?

Thanks for reading.

Selecting individual column names does find the correct information, only the default * style select is giving me a bad list of attributes. If I prefix the star with the table name, it returns correctly. Also, if I change the connection CCSID to 65535, it returns all 57 columns, though the character fields are wrongly encoded. Changing the naming parameter to 1 (SYSTEM) also fetches the right columns.

sarahkemp commented 7 years ago

This issue continues with all kinds of changes to tables. Today I changed extended the length of the field but my application continued to reject data as being too long though it now fit (on an insert statement this time). Again the issue could be overcome by switching the 'naming' parameter to 1, and I found today that changing the 'unicodeSql' parameter to 1 also got around the error. Unfortunately I do not know enough about this driver or these parameters to say why they act this way...

cooperl22 commented 7 years ago

Hi.

It is an issue about CCSID on your IBMi I guess.

Check it by issuing this command : DSPSYSVAL QCCSID It will give you the default system value.

Check also your account value : DSPUSRPRF

the value 65535 is evil.

The thing is that you seem to be American or British or English speaking people... so you shouldn't have issues with latin characters as I'm used to ;-) ...

Try using CCSID 1208 (unicode), 37 (US) in the ODBC keywords of the connection settings.

sarahkemp commented 7 years ago

American, yes - and our lead programmer has never been one to concern himself with special characters. The system CCSID is 37. The ODBC CCSID is 1208, and I have made a few tables on the system with 1208 columns as needed.

Perhaps these not matching is contributing to this problem? I haven't noticed it since my last post when I changed the unicodeSql parameter to '1'. Since I updated to 5.4.4.2 it is back to 0 though - must have missed it in my config update. I think I will leave it at zero and see if this issue starts coming up again...

I know this is a difficult issue and probably not reproducible outside my system. It is helpful for me when the issue recurs though! I understand if you want to close it out - I only posted in case someone happened to have the same problem.

I was also using the ibm-iaccess-1.1.0.1-1.0.i386.deb driver on my old server, but recently moved to an LPAR on the iSeries so now I'm using ibm-iaccess-1.1.0.8-1.0.ppc64el.deb for my ODBC driver. I don't know if that will have any effect.

cooperl22 commented 7 years ago

Yes it has effect.

I saw benefits about unicode characters when I updated the iAccess ODBC driver.