Oracle FgetAttr

[Kluvanek Martin]

Honza Pazdziora wrote:
> On Tue, Oct 28, 2003 at 01:33:45AM +0100, Kluvanek Martin wrote:
> 
>> Pomooooc. Uz som z toho Oracle cely deprimovany.... Oracle 9i pod WIN NT
>> 4.00 WS pripadne WIN2000
> 
> 
> Nechci znit nezdvorile, ale proc mate pocit, ze svet bude takovy, jaky si ho
> predstavujete, a ne takovy, jaky je a jak ho popisuje dokumentace?
:-)
To vypada ako filozofia microsoftu...
Za svoje peniaze nedostanete to co chcete alebo potrebujete, ale to co sa nam
zda ze nepotrebujete.
Je mi jasne ze ista firma vyraba svoj produkt len koli tomu, aby na nom zarobila
peniaze a nie preto, aby bol komukolvek uzitocny.
Ak je niekomu nahodou i uzitocny, tak to je ciste jeho problem.

> No a? Tak to tak proste je. Ona to popisuje i dokumentace:
> 
> location	Directory location of file.
> 
> filename	File name, including extension (file type), without directory path.
> In Unix, the filename cannot end with /.
To co ste citoval sa ale pise LEN v popise u
FOPEN a nie FGETATTR. To je myslim chyba(dokumentacie).
Teraz mi je jasne ze to plati pre vsetkeho volajuce i interne FOPEN. Ale z 
dokumentacie to moc nevyplyva.
Ked hladam obmedzenia pre FGETATTR tak sa podivam na odstavec FGETATTR a 
pripadne vseobecne stati o knihovni. Tam nikde nic takeho nieje, u FGETATTR je len

location
  Directory location of the source file, a DIRECTORY_NAME from the 
ALL_DIRECTORIES view (case sensitive)

filename
  The name of the source file to be copied

a ani formalny odkaz na FOPEN.


> 
> Dokumentace UTL_FILE nespecifikuje, co se stane, pokud zavolate ten program v
> rozporu s tim, co je napsano jako korektni volani. Holt Vase verze orizne
> jakykoli adresarovy balast a vezme si z toho filename pouze jmeno souboru.
> Nedivil bych se, kdyby dalsi verze toto nedelala a rekla, ze ve jmenu souboru
> nemate co mit lomitka ci padajici lomitka, a kdyby jeste dalsi verze smazala
> vsechna data a prebootovala system.
> 
> Dokumentace rika, ze location je adresar a filename jmeno souboru. Davejte
> tomu takove hodnoty, jake jsou podle dokumentace ocekavane.
Problem je v tom, ze velice podobny balicek SYS.DBMS_LOB ktory by som ocakaval, 
ze sa bude pouzivat spolu s UTL_FILE,  sa pre istotu sprava
UPLNE inak.
Clovek by teda blahovo ocakaval (pretoze obidva balicky su sucast toho isteho
systemu od tej istej firmy), ze sa budu spravat stejne.
Neviem ako dalej riesit problem ked potrebujem mat evidovanych 40tisic suborov 
kazdy cca 4MB. Tie dat do jedneho adresara je pre mna technologicky problem.
Ked som ich ukladanie vyriesil v BFILE v adresarovej strukture a teraz to mam 
hodit za hlavu a zacat znovu uplne inak, pretoze ich nedokazem z PL/SQL 
archivovat ani mazat.
Preco si vyvojari oracle dali tolko prace a "vyvinuli" nove features (a patricne 
sa s tym chvalia v http://otn.oracle.com/oramag/oracle/02-sep/o52plsql.html) 
ktore su len velmi obmedzene a z mojho pohladu celkom nezmyselne...Predsastejne 
meno suboru a cestu k nemu musia poskladat z LOCATION+FILENAME a je sumafuk kde 
su lomitka. A pokial to nieje tak preco sa tak nespravaju vsetky balicky.
?

Ale ako hovorite svet nieje ani taky, ako by sme chceli, ani taky ako si myslime 
ze je.



"Odchazim zhnusen pln nadseni z novych moznosti"


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz