Table refreshing/caching after update

Lieutenant_Bob · 2006-12-14

Hi!

Just a quick question:

When Navision 4.0SP3 is installed, Navision uses some kind of caching of the tables. In my particular problem I am using a <table>.GET with the primary key, and I need Navision to retrieve the record from the MSSQL database. However, the Navision client does not retrieve it from the database, but from some kind of cache somewhere. This is normally not a problem, because Navision keeps a tight "clean/dirty" concept. In this particular case, thought, the record I am retrieving has changed in the database.

My question is:

Is there anyway to FORCE the client to allways retrieve a fresh copy of the record from the database?

Thanks for your time,

Bob

kine · 2006-12-14

:-k

Sorry, but it seems like problems is elsewhere. Can you describe more the problem? (there is just one command which can help you - SELECTLATESTVERSION).

Lieutenant_Bob · 2006-12-14

Thanks for taking time to read and understand.

I will explain a little deeper.

I have a polling batchjob, that runs from a Navision client. This batchjob has a certain line of code reading:

IF <table>.GET(Primary key) THEN
IF <table>.<StatusField> < 900 THEN
Exit(FALSE)
ELSE
DoStuff

I want to get to the DoStuff part, but when running both a trace on the SQL server, and Debug in Navision I can see that the record I retrieve in the GET statement has an "old" value in its StatusField. This value has been changed in the database, and is now large enough to pass the second IF statement. The Navision client does not retrieve the record from the database, but from somekind of cache. I know this for a fact, because if I close down the client, and run the batchjob again, it runs smoothly. I have also confirmed this with the Navision debugger, running an enterprise manager on the side. The navision record contains "old" data, even though I just used the "get" method. A third confimation of the maner of the problem came from running a trace directly on the server, and seing that the client did not "SELECT" anything from that table, even when the GET method was called.

To keep it short (If I did not already mess that up) the record has changed since I ran the batchjob, and I need to tell the code that it HAS to read the record from the database, not from the cache.

Thanks again

Bob

kine · 2006-12-14

In this case, the SELECTLATESTVERSION will helps you...

SELECTLATESTVERSION;
IF <table>.GET(Primary key) THEN
  IF <table>.<StatusField> < 900 THEN
    Exit(FALSE)
  ELSE
    DoStuff

SELECTLATESTVERSION (Database)
This function forces the latest version of the database to be used.

SELECTLATESTVERSION
Comments
Navision Database Server
Due to the version principle, you are guaranteed that the database version that you use is consistent, even if you do some time-consuming processing, for example in a report, and other users update the database while the report is running.

In a situation where this is not desirable, and you need to use the latest version of data, you can use SELECTLATESTVERSION to enforce a reloading of the version that the client is using.

SQL Server
This function ensures that the data displayed is the most current data in the database. The function clears all non-locked records from the client cache, thereby ensuring that you read the most recent data.

Mbad · 2006-12-14

Nice one Kine

kine · 2006-12-14

Thanks, it is one year I needed same thing, now I can show off... 8)

Lieutenant_Bob · 2006-12-14

Thanks for your effort. I will test later today and let you know if you saved my day!

Bob

Lieutenant_Bob · 2006-12-14

It worked like a charm. I have now only grown 5 grey hairs today, instead of the usual 15.. ;-)

Thanks.

Bob

David_Singleton · 2006-12-14

Just one other note.

The debugger in Navision does not follow all the rules. And from one Navision version to the next it changes in how it addresses cache. In most conditions, the debugger bypasses the object and database cache, though it does maintain the version principle.

So basically you will often get some function that works fine when you debug, but differently when you run normally. So if sometimes you get situations where you see different versions of data int he debugger and normal, this is probably the issue.

Any way, your issue seems resolved, but keep in mind when you are debugging further.

kine · 2006-12-15

Lieutenant_Bob wrote:

It worked like a charm. I have now only grown 5 grey hairs today, instead of the usual 15.. ;-)

Thanks.

Bob

You are welcome...

David: thanks - it never come upon my mind that this happens. Sometime I fight with this "strange" bugs and differences, but I never thought about the object and data cache... good remark...

David_Singleton · 2006-12-16

kine wrote:

...
David: thanks - it never come upon my mind that this happens. Sometime I fight with this "strange" bugs and differences, but I never thought about the object and data cache... good remark...

This used to be taught as a part of developer training. These days I think programmers are just expected to work out fo them selves why it acts differently.

Table refreshing/caching after update

Comments

Categories