Full Unicode/Ansi-Support in /testing branch
Moderators: gto, EgonHugeist, 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?
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?
Oleg
- EgonHugeist
- Zeos Project Manager
- Posts: 1936
- Joined: 31.03.2011, 22:38
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?
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?
Best regards, Michael
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
@EgonHugeist
Almost good, but for:
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
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;
For Params [3] is assumed to be only the first value - 100.
Rev.1682, FireBird, D2006.
Michal
- EgonHugeist
- Zeos Project Manager
- Posts: 1936
- Joined: 31.03.2011, 22:38
olehs,
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.
I would say this is the best for the start too.about testcases, should I add define to them 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.
Best regards, Michael
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
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.
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.
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.Do you know if such double naming, here wrote, is valid for PostgreSQL too?
Oleg
@olehs
FireBird procedure:
Zeos for Delphi 2006 recognized as:
Michal
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;
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
- Zeos Project Manager
- Posts: 1936
- Joined: 31.03.2011, 22:38
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.
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.
Best regards, Michael
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
@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:
Michal
[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
- EgonHugeist
- Zeos Project Manager
- Posts: 1936
- Joined: 31.03.2011, 22:38
miab3,
And i solved again your report. Also did i upgrade the test to see if all params are used now. R1685
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.We must be careful to make sure that the dataset could find an answer.
And i solved again your report. Also did i upgrade the test to see if all params are used now. R1685
Best regards, Michael
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
@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
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
- Zeos Project Manager
- Posts: 1936
- Joined: 31.03.2011, 22:38
miab3,
great!
great!
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.( and their interaction is probably faster)
Best regards, Michael
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
- EgonHugeist
- Zeos Project Manager
- Posts: 1936
- Joined: 31.03.2011, 22:38
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?
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?
Best regards, Michael
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/
You want to help? http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
You found a (possible) bug? Use the new bugtracker dude! http://sourceforge.net/p/zeoslib/tickets/