Another strange one

Again a strange question. (It could be me coding crappy code or not being a good navision programmer but i keep that as a last resort option [:o] )) I have the following code. rec and samerec are pointing to the same table rec.get(key1,key2,key3); //Above code returns a record checking this in debugger samerec.reset; samerec.setrange(key1,rec.key1); samerec.setrange(key2,rec.key2); if samerec.find(’-’) then begin etc… etc… etc… end else message(‘Impossible???’); sometimes the code samerec.find does not find any record. this should be impossible. using the debugger i check the table filter and try that filter on the database, and ofcourse there is data. but the function still doesn’t find any record. My setup is NF2.6d+NT4(SP6a)+SQL7(SP3) Is this an error or am i in error

Hello Mario. What type of fields are key1 and key2. Please note that we found some wierd things happening with filtering in 2.60 prior to 2.60.E. The problem was maily with date and boolean fields. Yes, 2.60.D was supposed to fix these problems; however, I still had some problems as I mentioned until we upgraded to 2.60.05 (E).

Hi, Is the table changing at all such that at some point the record existed but no long does? For 2.5/2.6x on SQL, the GET function caches records in memory on the client, for some period of time. The FIND(’-’) function does not, so will always be the latest data, but FIND(’=’) also does, so should give you the same as GET if caching is the cause. If you do a SELECTLATESTVERSION before the FIND, do you still see this behaviour? For SQL, this will clear the client cache. (Note: this is an internal cache, not the object or commit cache).

Hi robert, michael, The problem was not the Cache of the SQL, also the table wasn’t changing at the same time. (Although the info about the get statement and find(’=’) could come in handy sometime) The problem has been fixed though. I thought i was running NF 2.6D but in reality i was running NF 2.6B. After upgrading to NF 2.6E the problem went away. I had a situation in which i could accuratly reproduce the error every time. after upgrading the client the problem didn’t occur anymore. So this was an issue which navision fixed in version 6C,6D or 6E. But luckily my problems with SQL are not over. i posted another thread with yet another SQL? odity… Best regards ,

Hey all, sounds familar as well. Please see link: http://www.cdi.org/nuclear/nukesoftware.txt Any comments?

Microsoft’s answer to this specific problem reads: In the next version everything will be better Not that I ever heard about this problem before or had read Microsofts answer but Microsoft statements always read In the next version everything will be better ------- With best regards from Switzerland Marcus Fabian

Hi walter, Sorry to disappoint you but this was not a problem with SQL but rather a problem with the navision client. personally I must say that i think navision has done a poor job implementing SQL but that is just my own impression. On the other hand walter your document makes for interesting reading. Best regards,