FinSql 2.6e Crashes During Restore

FinSQL 2.6e crashing during restore. FINSQL closes without error message or warning. Operating system claims it has generated an error. Dr. Watson records event ID 4097 in the Application Log, “The application, generated an application error. The error occured on 09/03/01 @ 09:04:28.515. The error generated was c0000005 at address 1004EE0C ().” Server is SQL2000, SP1. File being restored is a backup from Financials 2.6 Navision database with customizations. Other tests: 1) The database.fbk that comes on the install CD restores to SQL without error. 2) Restore attempt on a different client fails with same error. 3) Another backup of the same database will not restore. Fails with same error. 4) Restore of the backup to a 2nd (non-SQL) Financials database is successful. 5) Since FinSQL appears to crash while attempting to restore Table 13 - Salesperson/Purchasers, removed all records from table 13 and 4 custom fields (using 2nd database). Did another backup and successfully restored the database to SQL. Clearly there was “something wrong” with Table 13 data or fields. <troll>If you know Navision very well, an exception error is quite enough documentation as to the cause of the error.</troll> Any Navi-SQL gurus out there care to guess what in Table13 caused the problem. (I don’t know yet, or I’d just tell you.) Jim Hollcraft NCSD, NCSP, MCSE, CNE, MCP, MST aka Skater drilldot.com - Unauthorized Navision News Edited by - Jim Hollcraft on 2001 Sep 03 22:50:10

Jim Just a wild card but non of the Custom fields were type DateFormula? Just for Information field type DateFormula is not supported by SQL! Table 13 - Salesperson/Purchasers, removed all records from table 13 and 4 custom fields David Cox email: david@mindsource.co.uk

David, I confirmed that adding a data formula to the Cronus database, backup and then attempting a restore to SQL will cause the crash/close. So that means you are . <troll>But I thought that the date formula was exception c0000006 at address 1005FE01.</troll> Anyway, Thanks. Jim Hollcraft NCSD, NCSP, MCSE, CNE, MCP, MST aka Skater drilldot.com - Unauthorized Navision News Edited by - Jim Hollcraft on 2001 Sep 03 22:48:28

Hi Jim has one of your custom fields been of type date? Before changing to SQL you should run the checking-codeunits that are described in the Upgrade-Toolkit. Maybe there was a value in a date-field that should have been corrected before upgrading. I do’nt know if that could cause that effect - just a shot in the dark (dates like 01.01.0001 for example are not allowed. There is a minimum date-value somewhere around 1750).

Richard, That was a good guess. The database did have bad dates in it, but the FinSQL program caught those errors and gave a very clear error message. Jim Jim Hollcraft NCSD, NCSP, MCSE, CNE, MCP, MST aka Skater drilldot.com - Unauthorized Navision News

We have the same problem during restore (index build) or during TestDB. W2K SP2, SQL2000 SP1, FinSQL 2.6E = blue screen. SQL without SP1 the SQL Server stops with an event like this: 2001-10-04 11:54:59.83 spid52 SQL Server-Assertion : Datei:<recbase.cpp>, Zeile=1375 Fehler bei Assertion=‘m_offBeginVar < m_SizeRec’. 2001-10-04 11:54:59.85 spid52 Fehler: 3624, Schweregrad: 20, Status: 1. Sometimes the restore is OK but TestDB shows an error in the SumIndex of table 21. Sometimes the error is table 17 or 20. We changed the hardware and had no errors. We are still on investigation.

But this isn’t the same problem. You are talking about exceptions in SQL Server; with differing behaviour depending on the presense of SP1. This problem is due to the DataFormula type not being supported by 2.6 SQL, and crashing the client because of that.

I am not sure if this problem has been solved yet, but … another SQL problem with backups. If you have a lower case character in a code field then you will not be able to make a backup with a SQL client. I am not sure about a restore, but I guess if you had managed to make a backup, it may not restore. PS the error message when this happens is not in English or any other language known to modern man. If this is the error, then the fix is just a simple piece of code:


MyCodeField := UPCASE(MyCodeField);
modify;

_________________________ David Singleton Navision Consultant since 1991 dmks22@home.com___________