Hi all-
Just rolled out a series of applications that have been a long time coming.  It's time to ask a few questions.  (But not all at once.)

We're occasionally getting an error 1007, "The row has been deleted since last cached for the table ...."
And 1008, “The row has been modified since last cached ….”
I really thought I had everything setup to avoid this.  I was certainly wrong.

Next step will be to put some code in place. Probably trap these errors, refresh the necessary table, and try again.  I don’t insist things work the way I think they will.  Too old for that.  But what am I misunderstanding?  Is there a solution with EDB settings?

I'm still using EDB 2.28 build one.  I'll be experimenting with an update within a week or so..


Server
Remote
ANSI
Defaults for session timing parameters.
Standard NULL: yes
Caching modules: no
Buffered I/O: no

Sesssion
Remote
Ansi
Defaults on Remote tab
Except IP address of course
Pessimistic file locking, default times
Row change detection checked
Force Buffer flushes to disk checked
Keep tables open checked

Thanks,
Judd
Judd

jkr


Two questions:

1. is the error message correct?
2. what are the transaction levels, are we talking high volume?

Roy Lambert

Hi Roy-
The error messages are correct, but confirming brought up an oddity.  Users are asked to send me the error messages, and sometimes they do.  .
1007's are in LogEvents.
1008's are not in the log.  But I have screen snapshots that were emailed to me. So they did happen.

As to the transaction levels, it's difficult for me to rate the volume.  

Qt has about 10 tables involved; averaged 250 trans/day over a 4 day period.
Inv trans; Also about 10 tables; about 20+ day
JobTimers: 7 tables, about 135 trans/day.  
PayrollTimers: 5 tables, averages about 75 trans/day
Schedule: 3 tables; can't count but I'll guess maybe 30 trans/day
A number of others, but nothing I can think of on the scale of what's above

And a lot of transactions won't hit all the tables included.  Difference in part between new and modified records

One other very serious issue, which I'm waiting on.  The EDBServer crashes every other day or so.  I need to look at notes on the updates past what I'm using and also try to gather some more data before tackling this one.
-----------------------------


Roy Lambert wrote:

jkr


Two questions:

1. is the error message correct?
2. what are the transaction levels, are we talking high volume?

Roy Lambert
Judd

jkr


What I meant by "1. is the error message correct?" is are they reporting correctly or are they reporting incorrectly - ie was the row deleted or not.

The transaction volumes don't look very likely to cause the issue.

I'd be very tempted to ignore these initially and concentrate on the server crashing. Solve that and these may disappear.

Roy Lambert

I can't speak for all cases.  I know for sure that in some cases the error has arisen, the user clicks OK, and they are able to proceed right into the record.  

The common functions are Browse window to Edit window.  The edit windows do not edit the data directly.  The data is put into memory tables, edited, and then saved.

I can see these errors arising when saving.  Two users shouldn't be able to modify the same quote, for example.  But there are parts of a quote that could be changed by another process.  Some error checking will take care of that.

But I should be able to prevent this from arising arising when going to edit a quote. That is what I'd hoped the various EDB settings would take care of.  User 1 saves a quote.  User 2 then modifies the quote, and then maybe it goes back to user 1.  There's lag time between them.  I should be able to take care of this also.  But maybe I'm misunderstanding the settings, and need to check the relevant items.

These are the ones I'm focused on:
 Row change detection
 Force Buffer flushes to disk checked
 Keep tables open checked
Judd

jkr


If you're putting the data into a memory table and editing that then you're destroying any control ElevateDB has over the prime database unless you're also locking the record in question, and if you're doing that there's no need for the memory table.

Unless, of course as often happens, I'm misunderstanding something.

Roy Lambert

I don't understand this.

Oh.  Maybe I do.  The data in the memory table stands apart from the DB data.  It has nothing to do with it until I go to post changes.  So EDB has no idea what I've done. That's correct.  But I have to read the record before posting to it.  The problem would be between the read and the post.  What makes sense to me is that the read is a cached record, and the post finds it changed.  If that's true, then something like a refresh should take care of it.  And that's what I'll do if I need to.  But that's also what I was hoping to accomplish with the settings I have, regarding flushing, etc. So I probably don't understand something here.

The memory table is KbmMemtable.  

I don't need to torture this issue.  I can do the refreshes and see what happens.  If you can clarify that would be great, but I can let it be if not.  I'll probably see you in another thread, as I really must get to work on the access errors occurring on the EDBServer shortly.

Thanks, Roy
Judd

jkr

Your analysis sounds about right - ElevateDB has no idea what's happened between your copying the data to the KbmMemtable and posting it back. The reverse also applies - KbmMemtable has no idea what's going on in ElevateDB.

Even if you used ElevateDB's built in memory table the same would apply since by copying the data to an in-memory table you're creating a new table that is divorced from the source of the data.

Roy Lambert