For me, it's not good.
I use Bookmark in all application !

Eric

>For me, it's not good.
>I use Bookmark in all application !

So do I but I've not had any problems with it.

Roy Lambert

On 12/15/2015 9:28 AM, M Eric Hubert wrote:

Since you cannot duplicate the issue with standalone app one needs to
look at this one step at a time.


>                      Application.processmessages;

What if you take this out - to eliminate any chance of re-entrancy.

I was going to ask if you use threads and maybe it's a multi-threading
issue but since you are calling processmessages is there any chance that
something else in your your code runs and tries to do anything with
TableBuffer table (this would be any type of event that might get
triggered because you processed messages)

Raul

Eric,

<< But it's seems that the problem is a problem ansi / Unicode. >>

If the problem was with the Ansi/Unicode changes, then the result would be reproducible every time.

Tim Young
Elevate Software
www.elevatesoft.com

Eric,

<< I can't reproduce the problem in a simple program but i found where is the problem. >>

I doubt very much if the bookmarks are the cause of the issue.  They may *affect* the end result, but they aren't the cause.

Is the table that you're updating hooked up to any data-aware controls ?  If so, then you could be running into a situation where the other dataset events are moving the row pointer or doing something else that is messing with the proper execution of the edit.  It would explain why you're not seeing the issue in a cut-down version of the same code.

Tim Young
Elevate Software
www.elevatesoft.com

It's a strange problem....
The program is not multi-thread. It's a batch program.
They are no event on component and none datasource. The program contain only dataset (standard table, temporary table, query).
EDB version before Unicode/Ansi merge work well and after don't work (i have re-tested with the same source code).
The problem depend of data. They are not special change on datas whose work and data whose don't work.
The only real change is the import record order in the insert.
I think that they are a memory problem allocation. Perhaps a delphi 7 bug in this situation.
I have tested with and without FastMM. I don't see any problem.
When i use Boorkmark, if i use primary index for move in the table, they are none error.

This program is critical for me.
I have decided of replace 2 temporary EDB table by ...... Dbisam or kbmtable (The two work well)

Thanks, To be continued if i have more information.

Tim

>I doubt very much if the bookmarks are the cause of the issue. They may *affect* the end result, but they aren't the cause.

Agreed

>Is the table that you're updating hooked up to any data-aware controls ? If so, then you could be running into a situation where the other dataset events are moving the row pointer or doing something else that is messing with the proper execution of the edit. It would explain why you're not seeing the issue in a cut-down version of the same code.

Hmm. Interesting thought, I know I've had similar things and had to remove controls one by one to identify the trouble. I'm not sure what events could give this sort of error though, mine were all things that happened after posting rather than at posting. Since, I think its a data mismatch problem,  I would guess that the most likely event would be OnValidate.

Like Raul I'm also wary of the Application.ProcessMessages and what impact that might be having.

I am still dubious that Eric has identified the source of the problem. It could be one of the error message not quite right or trail of errors things. The code presented as having the problem and the "fixed" code are different so that could well support your argument

I just had another wild thought

CREATE TEMPORARY TABLE "TMP328504715"

implies that the table names are being generated in some way - if that was out of sync so the wrong tables were being used it could explain everything.


I just love a good mystery - when its someone else's - off to try and fix my mail merge program now



Roy Lambert

Eric,

<< EDB version before Unicode/Ansi merge work well and after don't work (i have re-tested with the same source code). The problem depend of data. They are not special change on datas whose work and data whose don't work.
The only real change is the import record order in the insert. I think that they are a memory problem allocation. Perhaps a delphi 7 bug in this situation. >>

I doubt if it's a Delphi 7 bug. It could be a memory overwrite issue, or the mishandling of a buffer in EDB, but I couldn't say for sure without being able to run it here. It's also possible that something is causing an overwrite in *another area of the application*, the results of which are then manifested in this area of the code.

<< I have tested with and without FastMM. I don't see any problem. >>

That usually indicates that the problem isn't memory-related.  Using FastMM4 normally will find memory issues that the default D7 memory manager won't find.

Do you know how to turn on FastMM4's Full-Debug option ?  If so, then you may want to compile your application with it turned on and see if there's any issues with memory overwrites.  It won't affect EDB unless you're compiling against the EDB source code, but it will still tell you if there's an overwrite.

Tim Young
Elevate Software
www.elevatesoft.com

I have tested my program with Rad Studio xe10. It work without any modification.
For now, i can't migrate all the application with this version.
I have pacthed the program for not use EDB for this particular temporary table in Delphi 7.
It work.
FastMM in fulldebugmode detect none problem.
So ?
Thanks .... When i have time, to be continued

Eric,

<< I have tested my program with Rad Studio xe10. It work without any modification. >>

That's probably just a coincidence.

<< For now, i can't migrate all the application with this version.  I have pacthed the program for not use EDB for this particular temporary table in Delphi 7.  It work. FastMM in fulldebugmode detect none problem. So ? Thanks .... When i have time, to be continued >>

If you can package up your application source code in a .zip file and email it to me, I can find out pretty quickly what's going on.

Tim Young
Elevate Software
www.elevatesoft.com