.Myslim, ze s nejakym podobnym nestandardnim chovanim jsme se setkali v
pripade Oracle 9.2.0.1 driveru, ktere obsahovaly mimo jine i nekolik chybek
v tehle oblasti. Uz je to dele, ale problem byl mam dojem nejen s uzaviranim
pripojeneho resultsetu, ale i s tim, ze se sam statement neuvolnoval
korektne ackoliv by podle standardu mel pote co se spusti garbage
collector - urcite se vyplaci volat close primo na statementu stejne jako
predtim na resultsetu ktery byl pres statement vytvoren.

Prestoze javadoc u metody java.sql.Statement.close() tvrdi
 "A <code>Statement</code> object is automatically closed
     * when it is garbage collected. When a <code>Statement</code> object is
     * closed, its current <code>ResultSet</code> object, if one exists, is
     * also closed.  "
- nemusi byt obecne pravda ani prvni, ani druha veta, holt jako vzdy zalezi
na tom, jak se ten interface naimplementuje. Takze pokud si nejste
stoprocentne jisti (coz neni asi nikdy :-) ) tak by se ten close mel asi
volat vsude kde to jde...
Jinak - slo o oci8 driver, mozna ze u nativniho, ktery bohuzel pouzivat
nemuzeme, to funguje spravne, to nevim...

Uz je to sice hodne off topic od puvodniho tematu, ale napada mne napr.
mimodek i dalsi chyba na kterou jsme narazili v Oracle driverech se kterou
jsme se opravdu hodne hodne vyvztekali nez jsme na ni prisli - a to je
problem s datovym typem timestamp a jeho prevodem na javovsky Timestamp, u
ktereho se v pripade, ze je pocet milisekund nacteny z databaze 0 jako pocet
milisekund "naindukuje" jine cislo nezli 0.
Jinymi slovy, jak mi pomohl kolega Michal s upresnenim: pri cteni Timestamp
s 0 ms je vracena hodnota ms z posledniho cteneho Timestampu ktery mel ms <>
0. Jednoduse, pokud tam bylo 0 ms, tak ten driver jakoby ten udaj "ms" nijak
nemenil, takze tam zustala predesla hodnota.

 - tzn. pokud napr. pouzivate Oracle timestampy k overeni, jestli se Vam
zaznam nezmenil v mezidobi mezi dvema selecty, je dobre na podobne policko
pripojit primo na urovni databaze trigger, ktery nejenom ze pri updatu
nastavuje vzdy aktualni hodnotu casu, ale v pripade, ze pocet milisekund je
0, tak je trosicku postrci o milisekundu, aby nacitani pres JDBC do typu
Timestamp potom fungovalo spravne - my to delame momentalne takhle:

create or replace trigger TU_BC_COUNTRY
before update on BC_COUNTRY
for each row
declare
  locMs int;
  loc_current_GMT_timestamp TIMESTAMP(3);
begin
  loc_current_GMT_timestamp := current_timestamp at time zone 'GMT';
  :new.CHANGE_DATE := loc_current_GMT_timestamp;

  locMs := mod(extract(second from :new.CHANGE_DATE) * 1000, 1000);
  if (locMs = 0) then
    -- tady je to postrceni o milisekundu, pokud je pocet milisekund roven
0:
    :new.CHANGE_DATE := :new.CHANGE_DATE + numtodsinterval(0.001, 'SECOND');
  end if;

  :new.CREATE_DATE := :old.CREATE_DATE;
  :new.CREATE_USER_LOGIN := :old.CREATE_USER_LOGIN;
end;
/

neprisli jsme na jiny zpusob jak se s tim vyporadat.

U verze 10.2 oracle driveru snad uz je to opravene...


    Ahoj,

        Archie.

-..--- Original Message ----- 
From: "Roman Kratochvil" <[EMAIL PROTECTED]>
To: "Java" <[email protected]>
Sent: Wednesday, August 23, 2006 8:42 PM
Subject: Re: for vs. while


To, ze je to zrovna ResultSet, byl jenom priklad, o to mi primarne neslo.
Nicmene faktem je, ze jsem se zatim nesetkal (troufam si tvrdit) s JDBC
driverem, ktery by ty ResultSety nezaviral pri zavreni Statementu (ten
samozrejme zaviram ve finally...). Delal jsem s MSSQL2000, 2005 (drivery od
MS i jTds), MySQL 3.x, 4.x (drivery org.gjt.mm.mysql* i com.mysql.*), HSQLDB
1.7.x. Myslim, ze i s Oracle 8.5 nebyl problem, ale to uz je davno, mozna se
pletu (resp. mozna to tehdy bylo psane jinak). Mohl bych se poucit, s jakymi
DB/drivery jste zazili problemy?

Diky

Roman


----- Original Message ----- 
From: "Moravec Jan" <[EMAIL PROTECTED]>
To: "Java" <[email protected]>
Sent: Wednesday, August 23, 2006 5:29 PM
Subject: RE: for vs. while


> No jo, ale ve finally ten RS nezavrete, kdyz to je lokalni promenna toho
> cyklu. Takze v ty podobe v jake to bylo presentovano, tj.
>
> for (ResultSet res=...; res.next(); )
> {
> }
>
> je to spise hezky antipattern.
>
> H.
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Stanislav Ošmera
> Sent: Wednesday, August 23, 2006 4:41 PM
> To: Java
> Subject: Re: for vs. while
>
>
> On 8/23/06, Moravec Jan <[EMAIL PROTECTED]> wrote:
>> Zdravim,
>>
>> Asi jsem neco nepochopil, ale jak korektne uzavrete ten otevreny result
>> set bez toho, ze byste spolehal na to, ze se to "mozna udela samo" pri
>> zavirani prepared statementu?
>>
>> Nedoporucuji na prilis spolehat na to, ze se ResultSet uzavre v okamziku
>> uzavreni statementu (to rika javadoc u ResultSet.close).
>
> Presne, drive jsem se na to spolehal az jsem jednou dost narazil a
> musel to prepisovat vsude. Myslim mozna ze je to napsano i v tom
> Blochovy ze resultset vzdy zavirat ve finally bloku, nikdy se
> nespolehat na zadnou automatiku
>
>
> -- 
> Stanislav Ošmera
> Work: +44 (0)2075 980 348
> Cell: +44 (0)7914 635 412
> private email: [EMAIL PROTECTED]
> work email: [EMAIL PROTECTED]
> Skype: sosmera   ICQ:149634231
>

Odpovedet emailem