From: Alexandre B. S. <ib...@th...> - 2004-02-27 22:13:00
|
At 22:18 27/02/2004 +0200, you wrote: > if count BLR_SEND > 2 then procedure use SUSPEND >only it's time requires for parse Hi Vladimir, This could be cached ? (Parse the BLR code on time and cache if that procedure was Selectable or Executable ? I don't think the procedure type should change frequently... So it is almost safe... Don't know about speed but to have a hash or MD5 of procedure BLR and check if it has changed could be quickly than parse it again ???) > > it are there... Any way asking to in FB 2.0 to add a filed to > > RDB$Procedures to store if the procedure is "selectable" or "executable" > > could be good too... > > They and so have a lot of ideas and problems :-) > Magnus Johansson offers for the final decision variant > expansions of options DSN > >added 3 position > - default > - only select from procedure > - only execute procedure > > Your opinion? If I understood correctly, will be add another option to DNS to tell if the procedure should be Execute with "execute" or "select" ? What the "default" will do ? To my problem I could set de DSN to "select only" since my problem with ODBC is with Crystal, and from Crystal Reports I just "select * from procedure"... But the guys who have a system that uses ODBC to connect could be stucked, if they choose "select only" crystal will works ok, but the TStoredProcedure.ExecProc will fail right ? If he chooses "exec only", TStoredProc.ExecProc will suceed, but Crystal will fail... I still prefer the idea of "ODBC driver" knows how to execute each type of procedure. A small penalty (some miliseconds to parse the entire BLR ?) could be accepted I think. >-- >Best regards, >Vladimir Tsvigun See You ! Alexandre Benson Smith Development THOR Software e Comercial Ltda. Santo Andre - Sao Paulo - Brazil www.thorsoftware.com.br |