Hi all, I’m having a problem at one of my clients. They recently has upgraded from a 2.60d to a 3.60hf24. One of the additions we have made for this client, is an integration with another system (NF2.60b native). Dataexchange is made trough txt-files. They have a test-functionality for the files, that they run before importing. This test-functionality has been directly moved from the 2.60 DB. (a report, based on tb7, calls a dataport OnPreReport that checks the individual lines, and inserts errormessages in tb7. OnPostDataItem I delete the inserted lines) In some cases we encounter a problem: finsql.exe has generated an error… My first guess was that I had some sort of deadlock on the sql-server, but I also experienced this error in a DB that I was the only user of. I don’t think that this has to do with too little memory, since I also have experienced to be succesfull with a file that is much larger (and with more errors) than a file that generates this error. Hope that someone has any ideas. TIA regards Alexander
Is there code that goes with it?[Duh!]
Hi David, The answer is: Yes. (C/AL-code, no error-codes [:D]) The actual testfunction is rather long, but every individual test is structured more or less like this:
IF NOT GLAccRec.GET(AccountNoVar) then // AccountNoVar from file IF NOT GLAccRecTemp.GET(AccountNoVar) THEN BEGIN GLAccRecTemp."No." := AccountNoVar; GLAccRecTemp.INSERT(); InsertErrorLine(1,AccountNoVar,''); END; ELSE IF GLAccRec.Blocked THEN IF NOT GLAccRecTemp2.GET(AccountNoVar) THEN BEGIN GLAccRecTemp2."No." := AccountNoVar; GLAccRecTemp2.INSERT(); InsertErrorLine(2,AccountNoVar,''); END; The function InsertErrorLines inserts new records in tb7, and “Description” is defined from the first parameter. Hope this will give you a clue of how my function works. (I could also send you the objects, but the code is in danish [:I], so I guess that it will make very little sesnse to you. regards Alexander
The code looks simple enough, there are the obvious questions, like are these defined as temp records etc, but I assume you are passed that stage. Are you able to determine if it is a C/Side line of code that triggeres the error. If so, cna you get the code down to a simple few lines that generat teh error. Have you tried it on native 3.60 to see if it works there. Also out of curiosity, why 3.60 and not 3.70? 3.70 SQL is a lot better.
I’m not able to “catch” the error with the debugger, wich indicates to me that the problem is not in my code, but somewhere else. I haven’t been able to reproduce the error on a native DB. But also the error is only periodical. One user can get the error, and then an other can try with success on the same file. Also One user can get the error, and if he/she tries again the next day, it might very well be a success. Why 3.60 and not 3.70? My client is a governmental institution. Large parts of the danish government runs a specialized version af MBS-Navision. This solution is controlled/developed centrally, so every institution that runs this solution, can either use 3.60SQL or 3.60SQL [V] (practically all of my other (private) clients, that run SQL, are on a 3.70) I’ve just heard from my client, that the danish government have put MBS on this issue. Apparently other institutions have reported the same problem, and it doesn’t seem to be limited to dataports. Others have reported the same, from many “areas” of Navision.
Thanks for the update.