7.2 testers-thread

[miab3]

@EgonHugeist,

R2884
How much is JulianEpoch

After addition:
ForceNativeResultSet=true
gets:
Operation is not allowed in FORWARD ONLY mode
when trying to open the DataSet with DbGrid.

Michal

[EgonHugeist]

It is not a simple mistake?
http://sourceforge.net/p/zeoslib/tickets/52/

No idea yet. I think he is right, but if there is NO test-case...
And the IsMatch() thing is a bit weired. A RegEx unit for our filters would be cool to have.

After addition:
ForceNativeResultSet=true
gets:
Operation is not allowed in FORWARD ONLY mode
when trying to open the DataSet with DbGrid.

Don't think about using it on Component-Level. This is for fast Dbc-Access only. As i wrote several times before: SQLite is a pure sequential driver. If a fetch is incomplete and another query trys to work with the fetching table you'll get an Exception "Table is Locked". That's why Zeos currently fetch all rows, cache them and return a resultset afterwards.
I'm using this option for fetching the metainformations to speed up the fetching time and for the performance tests. Also pure DBC users like AB from Synopse-project can use it even because they know about this "locked" issue. Other drivers like DBlib are forward only too but they allow simply editing the data of the fetching table.

JulianEpoch is fixed. Is a FPC constant an missing in Delphi. If you setup a new SQLite-Database than you can add "BindDoubleDateTimeValues=True" and Zeos writes/reads double values which is propable faster than the native strings... But don't use it for existing Table, because a 'Select xx from yy where ADateField=:Param1' will fail. SQLite is mixing the data in same column. RowX1/FieldY can be Text, RowX2/FieldY can be double. Not interesting for writing or reading. Zeos supports that, but a where compare fails on SQLite side.

[miab3]

@EgonHugeist, @mdaems,

Zeos7.2-alpha branches_ testing_R2890:
http://svn.code.sf.net/p/zeoslib/code-0 ... sting-7.2/
compiles and runs on (I have tested):
- Delphi XE2 32/64 -> C++(32)
Windows 8.1A pro-64 - C2D

Michal

[miab3]

@EgonHugeist, @mdaems,

Still do not understand why you can not publish
integer fix for FB and fix and package for XE5 in
http://svn.code.sf.net/p/zeoslib/code-0 ... 1-patches/
Why is this branch?

Michal

[EgonHugeist]

Still do not understand why you can not publish
integer fix for FB and fix and package for XE5 in
http://svn.code.sf.net/p/zeoslib/code-0 ... 1-patches/
Why is this branch?

all 7.x > 7.2 marked fixes where merged to 7.1 soon. 7.0 isn't maintained anymore. Mrk did merge 7.2 to trunk last days. The 7.1 fixes follow up soon. If Mark can't do the merges than i'll do them, Michal

[miab3]

@EgonHugeist,

Michael,
I speak about two evident fixes to 7.1.2-stable, for which was planned branch:
http://svn.code.sf.net/p/zeoslib/code-0 ... 1-patches/

Michal

[EgonHugeist]

Miab3

i know and i did understand you. As i wrote: The fixes for 7.1-patches comming soon. Either Mark is doing the job @middle of this week or i'll do it @end of this week. But commit time should be a week ago.

[miab3]

@EgonHugeist, @mdaems,

On Ticket #51 and #53.
In both cases there is a field called 'name'.
Maybe it has any significance?

Michal

[miab3]

@EgonHugeist, @mdaems,

Zeos7.1.2-stable-(patches) branches_ patches_R2896:
http://svn.code.sf.net/p/zeoslib/code-0 ... .1-patches/
compiles and runs on (I have tested):

- D2006,
- D2007 -> C++,
- DXE2 32/64 -> C++(32),
- Lazarus Windows7-64 1.1.0/fpc 2.7.1 32/64 (CodeTyphon ver 4.40),
(For Linux currently I have no way to test)

Firebird 2.5.3, MySQL 5.5.18, MariaDB 5.5.32, PostgreSQL 9.3.0.1, MSSQL 2008 R2 Express(mssql, FreeTDS, ado-sqlncli), *.mdb-ado-Jet.OLEDB.4.0, SQLite 3.7.17.

Wow
It seems that you can not make any mistake.
Bravo Michael.

Michal

[miab3]

@EgonHugeist, @mdaems,

Zeos7.2-alpha branches_ testing_R2892:
http://svn.code.sf.net/p/zeoslib/code-0 ... sting-7.2/
compiles and runs on (I have tested):
- Delphi XE2 32/64 -> C++(32)
Windows 8.1A pro-64 - C2D

Something really is not too good with update for PostgreSQL in 7.1.2 and 7.2.

Michal

[EgonHugeist]

@Miab3

On Ticket #51 and #53.
In both cases there is a field called 'name'.
Maybe it has any significance?

Nope, actually a made a local testcase. the field "name" is working propably on my side so it's a spezial case i can't reproduce yet. The Serial thing of http://sourceforge.net/p/zeoslib/tickets/53/ i've checked too. All approches to reproduce an possible issue do fail. Zeos determines the next serial allways for insertiation. But there are known issues in multi user environment and transactional states: http://stackoverflow.com/questions/2944 ... nserted-id f.e.

Wow
It seems that you can not make any mistake.
Bravo Michael.

Thanks for the aproval, Michal. But as you know i'm not perfekt. Sometimes there happen things accidential. The merge was a bit complicated. Not because of backporting the code, nope the new two tests "TestEmptyLob" and "TestParamUx" did kill the whole tests. 7.1 wasn't prepared for these cases. Just fixed everything ((:

The PG issues are nasty. I would be able to fix them if i simply could reproduce the issues.
For the serial thing i think it would be better to use the "returning id" clause. But it's not so simple because this clause retrieves ALL id's! Hmpf it'll take a while and some more testcase are required.

[miab3]

@EgonHugeist,

Michael,
Now in the zeos 7.2 is worse than in zeos 7.1.2.
I attach the logs of the same application (Delphi XE2-32, PostgreSQL 9.3).
If you try to update 7.1.2 running 7.2 gives an error.

pg1_z712p_2896.txt

pg1_z72_2892.txt

pg1_z72_2892.png

Michal

[EgonHugeist]

@Miab3,

did compare your logs. The only "real" diff i see is this:

7.1.2:
...1997-02-25,'WZ578',78,22,'WZ',

7.2
....1997-02-25 00:00:00.001,'WZ578',78,11,'WZ

is that right? Could you attach something "better" reproduceable, please?

[miab3]

@EgonHugeist,

Earlier, the more they differ despite the same sequence of actions and identical application.
Now I wonder where it comes from is .001 in datetime.

Michal

[miab3]

@EgonHugeist,

Michael,
This inaccuracy .001 (in 7.2) can not be the cause of the error?
This field is for me a timestamptz and has a value of
1997-02-25 (1997-02-25 00:00:00+01)

Michal