Šta ti generiše taj UID, možda neka UDF biblioteka? Ako je tako, testiraj posebno tu f-ju i vidi
da li vraća taj UID kako treba..
Pozdrav.

Kojeg ti je tipa kolona LOGTIME?
Ako koristiš DIALECT3, i ako je kolona tipa TIMESTAMP onda probaj ovako:

a ako je kolona tipa TIME onda:

Hvala na odgovorima. Firebird je zaista stabilan i pouzdan, vec dugo ga koristim, ali ovog puta je nesto uspeo da zezne. Nakon sto je odradjen backup/restore procedura je proradila... Pre toga sam svasta probao, ukljucujuci i pravljenje kopije iste te tabele u koju sam hteo da ubacujem podatke, pod drugim imenom, i tada je procedura radila. Pa drop kopije/re-create originala, ali nije vredelo.

Da nisi možda sam to prouzrokovao? Možda si mijenjao proceduru
dok su i drugi bili zakačeni na bazu i radili, ili nešto slično?
Nije loše utvrditi uzrok, da se ne bi ponavljalo.

Pa, mozda gresim, ali mislim da je dozvoljeno menjati stored procedure dok su korisnici aktivni? Bar do sada iz mog iskustva to nije dovodilo do problema.

> Pa, mozda gresim, ali mislim da je dozvoljeno menjati stored procedure dok su korisnici aktivni? Bar do sada iz mog iskustva to nije dovodilo do problema.:;

Dozvoljeno jeste, ali korisnici će nastaviti da rade keširanom (starom) verzijom procedure sve dok se ne zatvori i poslednja konekcija. Metadate izmene je preporučljivo raditi kao ekskluzivan korisnik.

Znam da korisnici nece videti promene sve dok se ne uloguju sledeci put, to je ok.

U stvari zavisi sa kojom arhitekturom radis. Ako je Classic, svako vidi staru verziju dok se ne konektuje. Ako je SuperServer, onda je dovoljno zatvoriti sve transakcije bez diskonektovanja. Naravno, ako radis u Delphiju ili necem slicnom gde ti stalno neke komponente drze otvorene transakcije onda ti to i ne vredi puno, ali ako imas npr. web aplikaciju onda nema problema.

> U stvari zavisi sa kojom arhitekturom radis. Ako je Classic, svako vidi staru verziju dok se ne konektuje. Ako
> je SuperServer, onda je dovoljno zatvoriti sve transakcije bez diskonektovanja. Naravno, ako radis u

Da li si siguran, meni je u glavi da se keširanje vrši na nivou konekcije.

> Delphiju ili necem slicnom gde ti stalno neke komponente drze otvorene transakcije onda ti to i ne vredi puno,

Nema komponenti koje će same od sebe to raditi, to zavisi od programera.

Classic na nivou konekcije, SuperServer ima shared cache, tj. sve konekcije vide isti metadata. Prakticno kada u jednoj transakciji promenis proceduru, svaka novootvorena transakija ce je videti - cak i ako imas neke druge otvorene transakcije. Uzmi slobodno neki admin. alat pa probaj.



Moguce da sam nesto pobrkao u vezi toga, nisam koristio Delphi vec 4 godine ili tako nesto. Koliko se secam dok je bio BDE i IBO imaju neki svoj cache koji ostaje dok se konekcija ne ugasi. Ali mozda i gresim u vezi toga... Neki Delphi expert ce znati bolje.

Negde sam pročitao da ne možeš raditi bezbroj izmena na FB bazi, a da ne uradiš backup/restore. Onda ti se dese ovakve stvari - znači prilikom razvoja, ako puno menjaš strukturu baze, odradi backup/restore s vremena na vreme.

Sad ću možda da lupim, ali mislim da ima neki brojač izmena (verzija), pa kada on dođe do nekog maximuma onda počinju problemi. Prilikom restore se ti brojači resetuju.

Ovo vazi samo za tabele, gde postoji tzv. format i gde baza pamti prethodne formate kolona. Mozda malo da objasnim kako ovo funkcionise: recimo imas kolonu tipa decimal(8,4) i onda je sa ALTER TABLE .. ALTER COLUMN ... promenis da bude decimal(18,4). Posto tabela ima vec neke podatke u sebi koji su do sada cuvani kao 8,4 kada radis sa njima baza radi prevodjenje iz 8.4 u 18.4. Novouneti podaci se cuvaju u formatu 18.4 pa nema konverzije. Dakle, binarna reprezentacija podataka na disku nije ista. Da bi ovo bilo moguce, cuva se tzv. format tj. opis formata kolone u sistemskoj tabeli RDB$FORMATS. Takodje u RDB$RELATIONS postoji polje RDB$FORMAT koje pokazuje trenutni broj izmena te tabele.

E sad, problem je sto je polje koje cuva redni broj formata smallint, a nekad ovo bilo 8 bita kada se pravio prvi Interbase i zato ima ogranicenje od 256 razlicitih formata. Dakle, mozes napraviti maksimalno 255 izmena nad jednom tabelom (svaka ima svoj format) pre nego sto moras uraditi backup/restore. Backup zapisuje sve podatke u tekucem formatu (u primeru koji sam gore naveo decimal(18,4)) tako da nema vise potrebe pamtiti stari format.