TZQuery opens a temporary table, all fields are read-only？

[miab3]

Hey zhuyl,

If you refer to my example 22a.zip
This example was that somehow it works, not that it works perfectly.
That it is not read-only now.

I also observe problems with non-English characters, especially in Lazarus

Michał

[marsupilami]

Hello aehimself,

@ Jan,
Taking the example from here, with your modifications included the fields are still read only.

Could you please share the exact code that generates this? The problem is that with the dblib driver we need to be aware of a lot of side conditions.

[marsupilami]

Hello Michal,

1. It works for me (in conjunction with TZUpdateSQL).
I am enclosing an example:
22a.zip

Yes, it always should work under these conditions because then Zeos doesn't care about anything anymore. It just assumes that the user knows what to do.

2. What do you think about:
viewtopic.php?f=50&p=185826#p185826

I think it might be solved by my changes from today. But I am not sure. Please retest as suggested in that thread.

[marsupilami]

Hello zhuyl,

1. There is a problem with the SQL statement without a table, such as ‘select getdate()’. Debugging to unit ZSybaseAnalyser.pas: TZSybaseStatementAnalyser.DefineSelectSchemaFromQuery error.

I assume these problems are solved by todays changes.

2. Using temporary tables under SQL 2000 will cause errors. Debugging to the unit ZDbcDbLibMetadata.pas: exec tempdb.sys.sp_columns has an error, can you change it to exec tempdb.dbo.sp_columns to be compatible with SQL2000?

I can change that. But I cannot test it because we don't have a test case for this.

3. When the data has non-English characters (such as Chinese), it will be wrong to save to the temporary table.

I assume this has to do with the next problem? Or is it independent from the next problem?

In addition, I found a problem that caused garbled characters, ZQuery1.FieldByName('CName').AsString:='程序abcd员', when garbled characters appeared when posting, debug to unit ZEncoding.pas: ZDetectUTF8Encoding function: if (EndPtr-Source > SizeOf(PCardinal)) and (PCardinal(Source)^ and $80808080 = 0) //Check quad block ASCII again
then inc(Source, SizeOf(PCardinal)) //SizeOf(PCardinal) here should be changed to: SizeOf(Cardinal)
else Inc(Source);

I will review and apply this change as soon as the test system has finished testing my other changes.

Best regards,

Jan

[marsupilami]

I also observe problems with non-English characters, especially in Lazarus

Could you please supply a test project that shows the problem? Otherwise I am not able to hunt down that bug.

[zhuyl]

hello marsupilami,

3. When the data has non-English characters (such as Chinese), it will be wrong to save to the temporary table.

Sorry, item 3 is not a problem, but I did not specify the client code page. Thank you for helping me solve the problem.

[zhuyl]

hello,
Now there is a new problem. When using ZQuery to modify a row of data, post and then edit, but without any modification, move to another row, move it back, and modify the data, an error will occur. I made a test project.

ZDetectUTF8Encoding, there is one place that has not been changed, and the two places marked in red need to be modified.

while Source < EndPtr do begin
c := Byte(Source^);
case c of
$00..$7F: //Ascii7
if (EndPtr - Source > SizeOf(PCardinal)) and (PCardinal(Source)^ and $80808080 = 0) //Check quad block ASCII again
then inc(Source, SizeOf(PCardinal))
else Inc(Source);

[miab3]

Hi All,

Now there is a new problem. When using ZQuery to modify a row of data, post and then edit, but without any modification, move to another row, move it back, and modify the data, an error will occur. I made a test project.

It looks like a very serious error to me!!!
"Previous" - does not work at all
"Next" - Doesn't "Post" before or does something else

Michał

[marsupilami]

Hello zhuyl,

hello,
Now there is a new problem. When using ZQuery to modify a row of data, post and then edit, but without any modification, move to another row, move it back, and modify the data, an error will occur. I made a test project.

Yes - there is. It seems that you found another bug in Zeos But it seems to not be related to the previous bug. This bug is related to a problem in TZAbstractCachedResultSet.RevertRecord -> RevertRecord marks a record as being deleted that later on gets used as a record to modify. RevertRecord gets called when ZQuery1.Cancel gets called. This bug should also happen on all other databases / drivers, I think, not only on dblib which makes it a quite serious bug indeed.
A side note: In your sample you call Previous. Previous is a method of TForm. You most probably want to call TZQuery.Prior, which is inherited from TDataset.

ZDetectUTF8Encoding, there is one place that has not been changed, and the two places marked in red need to be modified.

while Source < EndPtr do begin
c := Byte(Source^);
case c of
$00..$7F: //Ascii7
if (EndPtr - Source > SizeOf(PCardinal)) and (PCardinal(Source)^ and $80808080 = 0) //Check quad block ASCII again
then inc(Source, SizeOf(PCardinal))
else Inc(Source);

I applied these changes. Thank you.

[marsupilami]

"Previous" - does not work at all

As noted in my last post: Previous is a method of TForm. What really should be called is Prior.

"Next" - Doesn't "Post" before or does something else

I assume that Next does as it should. It calls Cancel because the record didn't get modified. If one calls Post before doing Next, the problem will not occur. If one calls Cancel before Next, the problem persists. The problem is in the internal record management of TZAbstractCachedResultset. I just don't have the time to debug this myself right now.

Best regards,

Jan

[miab3]

Hi Jan

You're right about that "Prior".

By the way, Cancel doesn't help in this case.

However, the convention in Delphi has always been that Next would perform a Post if the record was in the edit state.
Briefly speaking, sequence:

Last;
Edit;
Next;

Or:

Insert;
...
Next;

It shouldn't cause an error.

And here I associate this reported bug with dbMemo and the lack of remembering changes.

Anyway, both Prior and Next should do Post if the state is Edit

Michał

[marsupilami]

Hello zhuyl,

Now there is a new problem. When using ZQuery to modify a row of data, post and then edit, but without any modification, move to another row, move it back, and modify the data, an error will occur. I made a test project.

I spent quite some time to find out what happens here but failed for now. One question though: Why do you use CachedUpdates instead of transactions? Transactions should achieve the same but can track the changes of more than one query? Maybe to solve your problem it might make sense to change to using transactions?

To make sure, this isn't forgotten, I created a ticket: https://sourceforge.net/p/zeoslib/tickets/546/.

Best regards,

Jan

[zhuyl]

hello marsupilami,

We use zquery as a memory table, so CachedUpdates is used. My suggestion: When the current record is in the editing state, move the record back and forth to post automatically instead of cancel.

[marsupilami]

Hello zhuyl,

just to let you know - I had several gos at fixing this. But nothing worked without raising new errors. I will keep this in work but it might take time.

Regardiung the ause as an in memory table: If you don't want to save the data to the database, you could attach a TZUpdateSQL that has no statements set. This way you can select and keep the component from writing to the database without needing cached updates.

Best regards,

Jan

[zhuyl]

hello marsupilami,
thanks