error printing

dezarnau

Hi,

I have a big problem with my customer.

One user is posting shipments. When this user has finished, he tells to another user that he can print shipments which are not already printed.
The second user run the printing report by filtering "No. Printed" = 0.

My problem is that some shipments which have been printed and later re-printed are not the same. For example, on the first print, there are 5 lines, and on the reprint there are 7 lines. When i go see the form, there are 7 lines.


I don't understand why!?!

If anyone have already meet this problem or know where it could come from?

My customer runs Attain 3.60 on SQL Server SP3.

Thank you for your answer.

LG_Hellström

SQL.. one really must love that..

Check property TransactionType for the report where I guess you should go "Update", but I'm not an SQL master so pls. take your time in the F1 view.

Also, you'll get an error running this report from another object with a different TransactionType (e.g. default <UpdateNoLocks>) if you go ahead.

dezarnau

Thank you,

I looked at the property and the online help explain only 4 type (Browse, Snapshot, UpdateNoLocks and Update). But one more is available : Report.

Does someone know something about this one?

matteo_montanari

From help online:

Additionally, there is a Report option that maps to one of the basic options. This enables a report to use the most concurrent read-only form of data access for the connected server. When you use Navision Server, it maps to Snapshot whereas it maps to Browse for SQL Server 7.0.

Bye

Matteo

Scott_Frappier

The "Report" C/AL transaction looks to be the same as the "Browse" C/AL transaction type. The only key difference is how that transaction type maps to within the Navision Server from the SQL Server Option.

1.) The "Report" C/AL transaction type in SQL maps to the "Snapshot" transaction type in the Navision Server.
2.)The "Browse" C/AL transaction type in SQL maps to the "Browse" transaction type in the Navision Server.

Within SQL, both of these C/AL transaction types (Report,Browse) handle locking and reading in EXACTLY the same way. The isolation level that they utilize is Read Uncommitted.

The Read Uncommitted isolation level in SQL allows for the following to occur:
1.) Dirty Reads
2.) NonRepeatable Reads
3.) Phantoms

Dirty Read: Reading uncommitted data.

NonRepeatable Reads: A record is read from the database, is then changed by another user, and then the original user re-reads that record only to find that the values have changed since the initial read.

Phantoms: A record was created by one user, and then read by the other. In the middle of the transaction another task deletes the original record. Because the record was (and still is because the process is still continuing) read from the database for the second user, they have a record that does not exist in the database...but did at one point in time.


Is the person that is printing the shipment documents trying to print them at almost the exact same time the other user is posting the document? If so, can you move this to some sort of batch process?

If that’s not the case, then try modifying the transaction type's and see if it has the desired effect. The "Serializable" transaction type causes all 3 issues to disappear, but introduces locking issues (shared locks are issues on all rows and held until the end of the transaction instead of being freed after the row each row is read).

There could also be a client data-buffering problem. Try utilizing the SELECTLATESTVERSION. From the C/AL Help:
"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."

Hopefully, this is an over-abundance of information!

Good luck!