The operating system returned the error (1450)

bbrown · 2012-10-07

This is an old system runnign a C/Side 3.60 database with 5.0 SP1 cleints. The users have been reporting random occurences of the above error. I've finallly been able to isolate the problem to a set of what appears to be corrupt records in the Sales Line table.

A test of the secondary keys succeeds.
A test of the primary keys (and data) fails
Any attempt to touch these records fails (FIND, DELETE, COUNT)
I have exported all the other records, so I do have them.

ANy thoughts/ideas on how I may get past this problem? I don't work that much with native databases these days. So I'm a bit rusty on "the tricks".

David_Singleton · 2012-10-07

Unfortunately if the error is in the primary key there is a low chance of recovering those records. You could try creating a new key which needs to be unique, but not containing the primary keys, so find a combination of fields that will give you that. Ship date, item no., customer no. etc. BUT its most likely you will get an error in creating the key. If you don't get an error then you have a chance to create a report of maybe even dataport using that key and export the required records.

In the old days I used to fix a lot of these, and the best way was to get all the good records you could, then some how manually recreate the missing ones. You can use things like reservations and warehouse etc, but its never a guaranteed thing.

Of course another option is C/DART, but the politics of getting a license can be more hassle than its worth.

bbrown · 2012-10-07

I don't need to recover these records. I just need to get them out of the table. I've exported all the records that I need to retain. But any attempt to remove these records fails.

David_Singleton · 2012-10-07

bbrown wrote:

I don't need to recover these records. I just need to get them out of the table. I've exported all the records that I need to retain. But any attempt to remove these records fails.

DELETEALL(FALSE);

is generally the only function that works.

David_Singleton · 2012-10-07

If DELETEALL does not work, one other thing that sometimes works is to rename the table. Just go to object designer and over write 37 with e.g. 50037. Not an ideal solution, but at least it gets 37 free so you can move forward. Just be careful that links are also renumbered, so you should re-import ALL objects after the move.

bbrown · 2012-10-07

Tried that. ](*,)

David_Singleton · 2012-10-07

Try changing to the most unique key you have and then deleteall.

David_Singleton · 2012-10-07

Also try a non printing report sorted by a key that works and delete record by record followed by a commit.

bbrown · 2012-10-07

I've been attempting to delete them using a process only report and filtering for 1 order at a time with the following code:

T37.RESET;
T37.SETCURRENTKEY("Trans. No.","Trans. Line No.");
T37.SETRANGE("Document Type", "Sales Header"."Document Type");
T37.SETRANGE("Document No.", "Sales Header"."No.");
T37.DELETEALL(FALSE);

These orders are created from an external interface and the key ("Trans. No.","Trans. Line No.") is the unique reference to the other system.

David_Singleton · 2012-10-07

Did you try renumbering the table?

bbrown · 2012-10-07

David Singleton wrote:

Did you try renumbering the table?

Not following you here. Wouldn't that just give me an empty copy of my sales line table?

Per · 2012-10-07

As David mentioned is the trick to delete all records without actually touching the blocks in the database storing the bad records. This can be accomplished by a SalesLine.DELETEALL from a report or similar, but cannot be done by running the table or from the normal user interface.

After that should it be possible to backup the database since only the primary key of the current version is part of the backup (the reason for a restore building secondary keys for a very long time).

The only option I know is to delete all records in the table. Since the problem has been for a while is none of the tools used for roll-back of versions useful.

I found the list below with internal errors, but the 1450 is too new and not in the list :-)
http://wiki.dynamicsbook.com/index.php? ... r_messages

Per · 2012-10-07

You have to delete all record without a filter.

T37.RESET;
T37.DELETEALL(FALSE); // default
COMMIT;

If you apply a filter is the database working in the way that each record is retrieved (even with DELETEALL). That will touch the bad records and make it fail. With a DELETEALL without a filter is the pointer in the master table set to a blank (empty table). This causes no reading of the existing records and should not cause an error.

David_Singleton · 2012-10-07

I have fixed a lot of these in my day, and everyone is slightly different, some things work and somethings don't. So I am trying to remember some of the things I tried that worked at some stage.
One more I remember is to try to create a new primary key. So if you do have something that makes the records unique, try putting that at the top of the list.

David_Singleton · 2012-10-07

bbrown wrote:

David Singleton wrote:

Did you try renumbering the table?

Not following you here. Wouldn't that just give me an empty copy of my sales line table?

No it will move the data as well. Then you can rebuild it. You will still have a corrupt table (50027) but at least you can get on with fixing it.

bbrown · 2012-10-07

Per wrote:

As David mentioned is the trick to delete all records without actually touching the blocks in the database storing the bad records. This can be accomplished by a SalesLine.DELETEALL from a report or similar, but cannot be done by running the table or from the normal user interface.

After that should it be possible to backup the database since only the primary key of the current version is part of the backup (the reason for a restore building secondary keys for a very long time).

The only option I know is to delete all records in the table. Since the problem has been for a while is none of the tools used for roll-back of versions useful.

I found the list below with internal errors, but the 1450 is too new and not in the list :-)
http://wiki.dynamicsbook.com/index.php? ... r_messages

The 1450 is actually a Windows operating system error. So I'd not expect to find it in that list.

David_Singleton · 2012-10-07

Per wrote:

I found the list below with internal errors, but the 1450 is too new and not in the list :-)
http://wiki.dynamicsbook.com/index.php? ... r_messages

Excellent list that one.

bbrown · 2012-10-07

David Singleton wrote:

I have fixed a lot of these in my day, and everyone is slightly different, some things work and somethings don't. So I am trying to remember some of the things I tried that worked at some stage.
One more I remember is to try to create a new primary key. So if you do have something that makes the records unique, try putting that at the top of the list.

Fixed my share of these also. Just don't see that much native DB anymore. The tricks get a bit rusty.

David_Singleton · 2012-10-07

Sorry Brian, I should have made it clear that the DELETEALL needs to delete the entire table in one hit. As Per says, filtering on the table automatically changes that.

David_Singleton · 2012-10-07

bbrown wrote:

Fixed my share of these also. Just don't see that much native DB anymore. The tricks get a bit rusty.

Sadly a skill set that is no so much in demand since the move to SQL.

bbrown · 2012-10-07

Per wrote:

You have to delete all record without a filter.

T37.RESET;
T37.DELETEALL(FALSE); // default
COMMIT;

If you apply a filter is the database working in the way that each record is retrieved (even with DELETEALL). That will touch the bad records and make it fail. With a DELETEALL without a filter is the pointer in the master table set to a blank (empty table). This causes no reading of the existing records and should not cause an error.

David Singleton wrote:

bbrown wrote:

David Singleton wrote:

Did you try renumbering the table?

Not following you here. Wouldn't that just give me an empty copy of my sales line table?

No it will move the data as well. Then you can rebuild it. You will still have a corrupt table (50027) but at least you can get on with fixing it.

Now I just need to find my next "Window to Oppurtunity" for the database. This database host 7 companies including the one with the problem. It was hard enough getting the cleint to give me a couple hours on a Sunday. You've both given me something to try. Thanks, I will let you know how I do.

This is a large 200+ GB 3.60 database that we just need to limp thru a few more months. The cleint is in the middle of re-implmenting on NAV 2009 (not upgrading). But, as you can imagine, it's not a straight forward update. But rather involves a fair amount of process review and rethinking.

David_Singleton · 2012-10-07

David Singleton wrote:

Sorry Brian, I should have made it clear that the DELETEALL needs to delete the entire table in one hit. As Per says, filtering on the table automatically changes that.

Actually sometimes even running in the onbefore trigger of a report wont work, so try in a codeunit.

bbrown · 2012-10-09

I was able to get time on the system this evening. I exported the good records, did a DELETEALL(FALSE), and imported the good data. Ended up losing about 7000 records (from a total of 86000) but it's back up and running.

Thanks for the helps. Especially on a Sunday.

Howdy, Stranger!

Quick Links

Categories

The operating system returned the error (1450)

Answers