Page 26 of 44
Posted: 28.08.2012, 20:32
by 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?
Posted: 30.08.2012, 02:01
by 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?
Posted: 30.08.2012, 07:01
by 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?
Posted: 30.08.2012, 09:34
by 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.
Posted: 30.08.2012, 09:42
by 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
Posted: 30.08.2012, 10:13
by 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.
Posted: 30.08.2012, 10:39
by 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.
Posted: 30.08.2012, 10:58
by 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
Posted: 30.08.2012, 12:15
by 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.
Posted: 30.08.2012, 13:09
by 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
Posted: 31.08.2012, 00:21
by 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
Posted: 31.08.2012, 11:05
by 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
Posted: 31.08.2012, 22:37
by 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.
Posted: 01.09.2012, 16:13
by olehs
EgonHugeist, miab3,
Patch for Firebird's parameters order is done (rev.1689).
Posted: 01.09.2012, 17:22
by 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?