Page 34 of 44

Posted: 13.09.2012, 14:27
by miab3
EgonHugeist,

The names of procedures(MSSQL) is probably good, recognizing and returning types of parameters bad as before.
In fact, work properly only:

[dbo].CustOrderHist;1
[dbo].CustOrdersOrders;1

from Northwind Demo.

In ORACLE accuracy is not a problem but the special values.

Michal

Posted: 13.09.2012, 21:48
by olehs
EgonHugeist,

I saw you added GetOverloadSeparator and SupportsOverloadsInStoredProcedureName to the TZDatabaseInfo interface.

Let me give you some examples so you could think about the way of implementing overloads support (and see why I still didn't do it).

The way you are trying to do it only works with MSSQL, because overload index can be specified there right after a proc name (or can be ommited).
It could be fine with pure MSSQL driver, but miab3 is talking about ADO. I actually don't know how to determine what server we are connected to through Ado provider (it can be PostgreSQL)

Another problem is with quoted names. Let's look at pocedure like
CREATE PROCEDURE [A B T E S T]
In the GetProcedures listing it will appear like
A B T E S T;1
but to call it - you have to use
[A B T E S T];1

And another example
CREATE PROCEDURE [A B T E S T;1]
In the GetProcedures listing it will also appear like
A B T E S T;1
but it has to be call like
[A B T E S T;1] or [A B T E S T;1];1

Now about PostgreSQL.
Pg doesn't use identifiers to specify overloaded functions. It determines function to be used be types of in-parameters passed to it (like Pascal :)).
So a valid identifier would be in format that is passed to DROP FUNCTION, i.e.
set_card_data(character varying, integer, double precision)
or
set_card_data(character varying, integer, double precision, OUT character varying, OUT character varying)

But to accept this syntax from user we will need a separate parser, because
set_card_data(character varying, integer, double precision)
set_card_data(character varying, integer, double precision, OUT character varying, OUT character varying)
set_card_data(VARCHAR, INT4, double precision)
are identifiers of the same overloaded function.

Any ideas?

Posted: 13.09.2012, 21:52
by miab3
EgonHugeist,

FLOAT_COMPARE_PRECISION = 1.0e-5;
is correct in every version of Delphi and Lazarus :)

Michal

Posted: 14.09.2012, 08:40
by EgonHugeist
miab3,

yap, that's right. Rev 1796. Also di i remove all defines as much as possible...

Michal, i made a prepareation for the ADO Callable statment. starting @line 502 ZDbcADOStatment.pas. Could you please uncomment this code, comment to TVariant part and test if the reported issue is still present?

olehs,

slightly i got the imression we pushed the big red 'Do not touch me!' 'button. :lol: !
Pg doesn't use identifiers to specify overloaded functions. It determines function to be used be types of in-parameters passed to it (like Pascal Smile).
This is good to know. So i removed PostgreSQL from the databaseinfo list.
Any ideas?
not more then 1795, Oleg. I changed the SupportsOverloadsInStoredProcedureName to SupportsOverloadPrefixInStoredProcedureName and removed the getoverloadseparator funtion.

Now i go this way: if overload prefixes are valid for stored procedure names then DO NOT QUOTE the ObjectName in GetValueList. Nothing prevents a user to do it manually in the PropertyEditor, right?

For the first i settet only the ADO protocol to this list. I have no idea ho other databases do behave for that case. BUT could it be possible that the ADO/ODBC excepts stored procedures with this overload prefix? Could that be a common issue with this protocol? What happens with other servers? IF this is the case then we can reintroduce my improvement (i left the ExtractOverload function there).
[A B T E S T;1] or [A B T E S T;1];1
As far as i understoud the ADO with MsSQL behavior was the Overload allways added. The last case was imlemented.

If this changed design isn't safe too, then whe should remove this IdentifierQuoting again, write some comments to avoid others run into the same issue..

What do you think?

Posted: 14.09.2012, 10:01
by miab3
EgonHugeist,

Zeos7_branches_ testing_r1797
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: 14.09.2012, 10:40
by EgonHugeist
miab3,

Thank you, Michal.

May i point you to this again:
Michal, i made a prepareation for the ADO Callable statment. starting @line 502 ZDbcADOStatment.pas. Could you please uncomment this code, comment to TVariant part and test if the reported issue is still present?
I have still no ADO running...

Posted: 14.09.2012, 11:18
by miab3
EgonHugeist,

It did not change anything.

The messages I got when compiling:
[DCC Warning] ZDbcAdoStatement.pas(514): W1057 Implicit string cast from 'AnsiString' to 'string'
[DCC Hint] ZDbcAdoStatement.pas(491): H2164 Variable 'Stream' is declared but never used in 'TZAdoCallableStatement.GetOutParam'

Michal

Posted: 14.09.2012, 13:04
by miab3
EgonHugeist,

Do you really need the override in file ZAbstractRODataset.pas line 327:

Code: Select all

{$IFDEF WITH_TRECORDBUFFER}
    procedure ClearCalcFields(Buffer: TRecordBuffer); // M.A. override;
{$ELSE}
    procedure ClearCalcFields(Buffer: PChar);override;
{$ENDIF}
Michal

Posted: 14.09.2012, 14:48
by EgonHugeist
miab3,

Question: What is the effect of this patch? overriding virtual defined procedure is a clean code otherwise we got a compiler-warning...

Code: Select all

The messages I got when compiling:
[DCC Warning] ZDbcAdoStatement.pas(514): W1057 Implicit string cast from 'AnsiString' to 'string'
[DCC Hint] ZDbcAdoStatement.pas(491): H2164 Variable 'Stream' is declared but never used in 'TZAdoCallableStatement.GetOutParam'
yes these warnings are right! stream could be removed, but then the binaries are added....

Posted: 14.09.2012, 16:04
by miab3
EgonHugeist,

I wrote, any changes.
In the same situations the same erroneous behavior.

Michal

Posted: 16.09.2012, 16:19
by EgonHugeist
miab3,

Got now an ADO Server running and i use the 'ABTEST' procedure.

Found and fixed several issues. Also can i confirm the string returning issue after a second execution...
I played a while, but i've no solution. The out integer values are right. Also are the strings not trunced (i thought before). Actually i can't say what's wrong....

Michael did you test the procedure with another component/app+ADO then Zeos?

Posted: 18.09.2012, 18:48
by miab3
EgonHugeist,

Zeos7_branches_ testing_r1828
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: 19.09.2012, 11:22
by miab3
EgonHugeist, olehs,

I think I explained why PostgreSQL is so heavy.
6.X (7.x) does not support Cursor Fetch.
http://grokbase.com/p/postgresql/pgsql- ... or-gui-rad
A Zeos 5.5 so.

It is found in ZDirPgSql.pas in 5.5

Code: Select all

procedure TDirPgSqlQuery.Open;
var
  Temp: string;
begin
  inherited Open;
  SetStatus(qsFail);
  FLastInsertOid := 0;
  if not Assigned(Connect) then
    DatabaseError(SConnectNotDefined);
  if not Assigned(Transact) then
    DatabaseError(STransactNotDefined);
  if not (Connect.Active and Transact.Active) then
    Exit;

  { If it's a select query in Cursor mode, declare a new cursor }
  FCursorName := '';
  if UseCursor then
  begin
    Temp := Sql;
    if StrCaseCmp(StrTok(Temp, ' '#9#13#10), 'SELECT') then
      FCursorName := 'ZeosCursor_' + CursorGenerator;
  end;

  if FCursorName <> '' then
  begin
    Temp := ClearSpaces(Format('DECLARE %s CURSOR FOR %s', [FCursorName, Trim(Sql)]));
    FHandle := PQexec(TDirPgSqlTransact(Transact).Handle, PChar(Temp));
    MonitorList.InvokeEvent(Temp, Transact.Error, not Active);

    Temp := Format('FETCH FORWARD 1 FROM %s', [FCursorName]);
    FHandle := PQexec(TDirPgSqlTransact(Transact).Handle, PChar(Temp));
    MonitorList.InvokeEvent(Temp, Transact.Error, not Active);
  end
  else
  begin
    FHandle := PQexec(TDirPgSqlTransact(Transact).Handle,
      PChar(ClearSpaces(Trim(Sql))));
  end;

  if Assigned(FHandle) then
  begin
    if Transact.Error = '' then
    begin
      SetActive(True);
      SetStatus(qsTuplesOk);
      inherited First;
    end
    else
    begin
      PQclear(FHandle);
      FHandle := nil;
    end;
  end;
  MonitorList.InvokeEvent(Sql, Transact.Error, not Active);
end;
Michal

Posted: 19.09.2012, 14:02
by EgonHugeist
miab3,

Where did you get the code from? It might be a nice proposal for Oleg..

Michal, i got a free Sybase SQL Anywhere 12 running and fixed the most issues of the ASA protocol. You can test this server too if you doubt.

Added protocol 'ASA12'

Posted: 19.09.2012, 14:09
by miab3
EgonHugeist,

ZEOS 5.5? from:
http://sourceforge.net/projects/zeoslib ... .0-stable/

How to take a free trial version of SQL Anywhere 12?

Michal