Full Unicode/Ansi-Support in /testing branch

[olehs]

miab3, EgonHugeist,

don't you think parameters should go in order they appear in function declaration?

Params[0] -> P1
Params[1] -> P2
Params[2] -> P3
Params[3] -> P4
Params[4] -> P5

And what about returnValue? I think (if there is such param) it also has to be at the end of parameter list.
What do you think?

[EgonHugeist]

miab3,

had a sleeples night with baby cry.. You AccessVioloaction of D7-2007 and the unreleased memory (tested 1.000.000 exeutions) should be solved now. Rev.1682 I hope this will help you until we are ready with discussing/fixing the TZStoredProc issues. I'll keep you up to date about this, Michal.

olehs,

according the parameter order: I must admit i like you proposal. But we have to fix the same behavior for all PlainDrivers (with a difine for the old behavior in this case) in one commit. This is a problem for me because actually i've no idea how to test the ASA plain and the whole DBLib i didn't test actually. So i propose to add a temporary define for the new behavior you plan (the correct one in my mind).

Michal, Oleg what you're thinking about?

[olehs]

EgonHugeist,

So i propose to add a temporary define for the new behavior you plan (the correct one in my mind).

agree. And what about testcases, should I add define to them too or just test the new behaviour?

[olehs]

EgonHugeist,

I looked at other drivers and as I can see, only Interbase creates outparams before inparams.
PG returns only returnValue at the beginning of the list.

So it looks like there won't be much work to implement new behaviour.

[miab3]

@EgonHugeist

Almost good, but for:

Code: Select all

begin
    ZStoredProc1.StoredProcName:= 'ABTEST';
    ZStoredProc1.Params[2].AsInteger:= 50;
    ZStoredProc1.Params[3].AsInteger:= 100;
    ZStoredProc1.Params[4].AsString:= 'a';
    ZStoredProc1.ExecProc;
    Edit1.Text:=ZStoredProc1.Params[0].AsString + ' ' + ZStoredProc1.Params[1].AsString;
    ZStoredProc1.Params[3].AsInteger:= 200;
//    ZStoredProc1.Unprepare;
    ZStoredProc1.ExecProc;
    Edit2.Text:=ZStoredProc1.Params[0].AsString + ' ' + ZStoredProc1.Params[1].AsString;
end;

the result is the same for both Edit.
For Params [3] is assumed to be only the first value - 100.

Rev.1682, FireBird, D2006.

Michal

[EgonHugeist]

olehs,

about testcases, should I add define to them too

I would say this is the best for the start too.
According the FireBird order, i must say i didn't check it yet. But having the parameters with the "creation" name AND order seems for me more logical then the actual behavior. What do you think about some more discussions with Mark? Do you know if such double naming, here wrote, is valid for PostgreSQL too?


miab3,
Thank you for that hint again. I'll prepare the testcase again to check the new issue too.

[olehs]

EgonHugeist,

if I remember right, Firebird has separate lists for in and out parameters, so there is no 'right' order for combination of them (miab3, maybe you can tell better?)

All the other databases, especially those supporting InOut params! have defined order.

Do you know if such double naming, here wrote, is valid for PostgreSQL too?

Yes, as I wrote to the Group, it's valid for PG, but I don't think it's critical. Let's discuss it with Mark.

[miab3]

@olehs

FireBird procedure:

Code: Select all

create or alter procedure ABTEST (
    P1 bigint,
    P2 bigint,
    P3 varchar(10))
returns (
    P4 bigint,
    P5 varchar(20))
as
begin
  P4 = P1 * 10 + P2;
  P5 = P3 || P3;
  suspend;

Zeos for Delphi 2006 recognized as:

Code: Select all

  object ZStoredProc1: TZStoredProc
    Connection = ZConnection1
    Params = <
      item
        DataType = ftLargeint
        Name = 'P4'
        ParamType = ptResult
      end
      item
        DataType = ftWideString
        Name = 'P5'
        ParamType = ptResult
      end
      item
        DataType = ftLargeint
        Name = 'P1'
        ParamType = ptInput
      end
      item
        DataType = ftLargeint
        Name = 'P2'
        ParamType = ptInput
      end
      item
        DataType = ftWideString
        Name = 'P3'
        ParamType = ptInput
      end>
    StoredProcName = 'ABTEST'
    Left = 780
    Top = 436
    ParamData = <
      item
        DataType = ftLargeint
        Name = 'P4'
        ParamType = ptResult
      end
      item
        DataType = ftWideString
        Name = 'P5'
        ParamType = ptResult
      end
      item
        DataType = ftLargeint
        Name = 'P1'
        ParamType = ptInput
      end
      item
        DataType = ftLargeint
        Name = 'P2'
        ParamType = ptInput
      end
      item
        DataType = ftWideString
        Name = 'P3'
        ParamType = ptInput
      end>
  end

Michal

[EgonHugeist]

olehs,

yes we'll discuss it in our group. Don't wait for reply until tonight there. Actually i'm writing from my smartphone..

miab3,

Thank you for these Details. I'll check if we can change the order to Input-Params first then OutputParams.

[miab3]

@EgonHugeist, @olehs

[s]I'm not sure, however, return values ​​should not be left at the beginning.[/s]
We must be careful to make sure that the dataset could find an answer.

This is the same as before for PostgreSQL:

Code: Select all

object ZStoredProc1: TZStoredProc
    Connection = ZConnection1
    Active = True
    Params = <
      item
        DataType = ftUnknown
        Name = 'returnValue'
        ParamType = ptResult
      end
      item
        DataType = ftInteger
        Name = 'p1'
        ParamType = ptInput
        Value = '50'
      end
      item
        DataType = ftInteger
        Name = 'p2'
        ParamType = ptInput
        Value = '100'
      end
      item
        DataType = ftWideString
        Name = 'p3'
        ParamType = ptInput
        Value = 'a'
      end>
    StoredProcName = 'abtest'
    Left = 628
    Top = 452
    ParamData = <
      item
        DataType = ftUnknown
        Name = 'returnValue'
        ParamType = ptResult
      end
      item
        DataType = ftInteger
        Name = 'p1'
        ParamType = ptInput
        Value = '50'
      end
      item
        DataType = ftInteger
        Name = 'p2'
        ParamType = ptInput
        Value = '100'
      end
      item
        DataType = ftWideString
        Name = 'p3'
        ParamType = ptInput
        Value = 'a'
      end>
  end

Michal

[EgonHugeist]

miab3,

We must be careful to make sure that the dataset could find an answer.

This is right, Michal. And the PostgreSQL behavior isn't fixed yet. Oleg did some preparations to do this. The "internal" discussion isn't done yet because there are really a lot of issues to expect with the stored procedures.

And i solved again your report. Also did i upgrade the test to see if all params are used now. R1685

[miab3]

@EgonHugeist

It seems that now the FireBird procedures all right,
( and their interaction is probably faster).
Thanks Michael,

Zeos7_branches_ testing_r1685
http://svn.code.sf.net/p/zeoslib/code-0 ... s/testing/
compiles and runs on (I have tested):

- D2006,
- D2007 -> C++,
- DXE2 32/64 -> C++32,
- Lazarus Win 1.1/fpc 2.7.1 32/64,
- Lazarus Lin 1.1/fpc 2.7.1 64 on Debian 64-bit (LMDE 201204).

Michal

[EgonHugeist]

miab3,

great!

( and their interaction is probably faster)

that's my impression too. I did partially rewrite the statement and i know why others are slow too, Michal. If i have the time then i'll rewrite the other statments too in this kind. Actually we've got two ultra fast Statemenat. The latest fixed FireBird callable statment and the added PostgreSQL RealPreparedStatement... But all others do work well and doing this is time wasting for now.

[olehs]

EgonHugeist, miab3,

Patch for Firebird's parameters order is done (rev.1689).

[EgonHugeist]

olehs,

had a look right now. Great job at all.

Oleg i know we talked a lot about the TZStoredProc component. But actually i've some fragments(not more than a start) of the PostgreSQL CAPI Prepared statement in my sources. (A time waster on merging allways the latest changes) And on MySQL the CallableStatement for the Stored procs is completely missing.

Which statement first?