Error 10050 application specified size of record does not match the database declared size

(0) Share

Report

Posted on by Coe-Ane Erasmus

455

Good day

we are testing the upgrade of SL 7 FP 1 to 2011 FP 1 , and receive this message on all screens while trying to release a batch. I have deleted all customizations from the database, and made sure that I run the upgrade of the db's in database maintenance using the correct permissions etc. The db build file after the upgrade does not show any errors. I have tried looking for mismatch in dh files etc. in the screens while in customization mode, but cannot find any related issues to the articles that I have read on the web. The screens also give the errors when running in standard mode. Can anyone assist? Thanks

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (1)

Suggested answer

Karthik Sellamuthu ... 1,202 on at

Like (0)

Report

Hi,

Can you check if any records in Custom2 table in system database associated with the screen, i believe the third party customizations would store in that table. Just query with screenid, let me know your findings.

Thanks,

Karthik

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

If still an issue, can you give a more complete error message.

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (0)

Report

You did not indicate one way or the other but I will assume that you ran the database update against the database as part of your upgrade. You also did not indicate the table related to the error but I suspect it could be GLSETUP which did have a size change with SL 2011 FP1.

I suggest you look at the DBBuild.log file that was created when running the database update process to see if it shows any errors. You will find that file on the C drive that ran the update under that user's document folder in a sub-folder called Microsoft Dynamics SL \ DB Maintenance Logs.

As a future suggestion, when posting something on this forum it is usually better to provide too much information as opposed to too little information in order to get the most accurate responses back as quickly as possible without a lot of back-and-forth exchanges.

Was this reply helpful? Yes No
Ajit Kannan 1,246 on at

Like (0)

Report

Hello,

Most customizations which do that will include a ".dh file", which lists all the fields in the table, their type, and size.

If any of that info changes in the new version, then you need to eliminate the old .dh file and bring in the New.dh file version.

One thing to be sure of, that the database is upgrade correctly.Because, If some fields have failed to upgrade, then you may have problems in the customizations.

Thanks,

Ajit Kannan S R

Was this reply helpful? Yes No
Coe-Ane Erasmus 455 on at

Like (0)

Report

Thank you for all the responses, I will include more detail in future!

1) I made sure that all customizations were deleted from custom, custom2 and customvba tables to ensure that the issue did not relate to any of our customizations.

2) I also tried to launch the screens in standard mode and try to post a transaction, and received the same error message.

3) I did review the db log file, and it only referenced some AD accounts that did not exist on our test server. I deleted those users and ran the upgrade process again. I also tried switching to SQL authentication and ran the upgrade again. None of these options seemed to fix the error message.

4) the exact error message references the pjtran table. The subtask_name field is listed in the schema, but does not look as though the table was upgraded to include this column.

Error message: "System Message 10050: The application specified size of record pjtran (859) does not match the database declared size (759)". This occurs in the journal transaction, invoice and memo, voucher and adjustment screens (these are the ones that I tested for now)

Was this reply helpful? Yes No
Verified answer

Coe-Ane Erasmus 455 on at

Like (0)

Report

For future reference. we isolated the issue - and it seems that it was permissions related. The size of our test VM was not big enough, and the result was that the dbbuild log file did not log all the errors during the upgrade. After freeing up some space and shrinking the log files, the dbbuild referenced permission errors. Even though the user that I was logged in with had admin rights on the PC, in SQL and to the folders, as well as specific permissions on the databases we were trying to upgrade, (including being db owner for the databases ), the dbbuild still indicated that the upgrade scripts could not be run as there were no specific rights for the pjtran and the ut_ upgrade scripts that had to be run. After giving specific rights to those stored procedures and the pjtran table, it seems that the upgrade ran through successfully. Thanks for all the suggestions.

Was this reply helpful? Yes No