Pre-SQL conversion data cleanup problems

We are attempting to migrate a 2.6 database from the internal format to a standard MS SQL format. Main reasons include realtime backups and 3rd party custom application integration (internally developed). In doing the conversion testing we alarmingly realized we have some corrupt data in the original DB during the restore process. Since the restore aborts at the 1st sign of trouble I am not sure how large of scope I have a problem. So far, I know that I have about 20 records with bad document dates in the G/L entry table. I can figure out the correct data and fix it, so in this case I fired up my C/ODBC connection to attempt the repair of the totally garbage dates and found that permissioning issues exist that will not allow us to complete the data repair (even under SUPER). I am not sure how this even happened in the 1st place since the date field we are fixing does not even have real dates. Items like “12345” and “11/1/0022” exist in the field. We do NOT have a developers license, nor can we afford one. I need to come up with a solution to fix the bad data so that we can continue the SQL conversion. Any cost-effective ways to accomplish the data repair would be greatly appreciated. Thanks for your time in reading my question. Phil Ciccone

First write a report that will look at all the tables that have dates in them and identify the records with the wrong Dates. Use the field table. filter it on datatype Date. use RecordReference to get the date and filter less than a date (1900). Send this report to your NSC to write a routine to clean the data. Without a developer license, you can’t modify historical documents or Ledgers.

Ahmed is correct. You will need to involve your (or another) NSC in this process.

Phil, to emphasise what the otehrs said here, ou need your NSC. But not just to correct this issue. The whole process of moving from C/SIDE to SQL is not a task you want to do yourselves. I am guessing that you are trying to ave money, butyou ust won’t. If there is some reason that you can’t involve your NSC, then at least get access to an independent consultant that knows Navision. And though unrelated, I hope you are aware that your exisitng Navision server won’t work with SQL, and will have to be rebuilt. I don’t want to scare you or anything, but I am sure that Navision is a key component of theday to day running of your company, and you can’t afford to mess with that. SQL whilst not s good as C/SIDE [:D] is a great platform with a lot of quirks that need specialist attention.

I have upgraded my 2.6 to sql 3 months ago. Before upgrading to sql, you must perform a lot of test (see documentation and migrate.fob) And one of these test is for bad date …