[ inherited @ 05.09.2006. 12:00 ] @
Ovako, napravio sam jednu tabelu sa atributima:
Code:

CREATE TABLE LICA (
  ID_LICA TEXT NOT NULL,
  IME TEXT NOT NULL,
  PREZIME TEXT NOT NULL,
  
  CONSTRAINT pk_LICA PRIMARY KEY (ID_LICA));

Na formi za unos podataka u tu tabelu odradio sam automatsko dodeljivanje ID_LICA:
Code:

...
var rb:integer;
begin
   with ADOLICA do begin
     Close;
     SQL.Clear;
     SQL.Add('SELECT TOP 1 ID_LICA FROM LICA');
     SQL.Add('ORDER BY ID_LICA DESC');
     Open;
     if ADOLICA.RecordCount=0 then
       rb := 10001
     else
       rb:= StrToInt(ADOLICA.FieldByName('ID_LICA').AsString)+1;
  end;
    IDLICA.Text:=IntToStr(rb);
...

Sta je problem, ako ima u tabeli ID_Lica: 10001, 10002, 10003, ..., 1000n i obrisem 10003, tad
slogovi se ne sloze redom, odnosno za jedan unazad, a automatsko dodavajne se nastavlja od poslednjeg
broja (DESC)!?!

Sta mi savetujete?
[ Bojan Kopanja @ 05.09.2006. 12:06 ] @
Logicno je da se nece svi ostali vratiti za jedan broj unazad... To moras sam da odradis tako sto ces proci kroz ostatak baze ( od obrisanog recorda pa na dalje ) i sam smanjiti ostalebrojeve za jedan.
[ inherited @ 05.09.2006. 13:51 ] @
OK, al, primer bi mi vise pomogao.
Znaci da svi slogovi ID_LICA se umanje za jedan, ali tad se narusava integritet baze!?!
Tada i relacije u bazi se menjaju!?!
[ savkic @ 05.09.2006. 14:34 ] @
> Znaci da svi slogovi ID_LICA se umanje za jedan, ali tad se narusava integritet baze!?!
> Tada i relacije u bazi se menjaju!?!

Koliko vidim tebi zapravo trebaju dva odvojena polja, jedno INTEGER koje će biti nosilac referencijalnog integriteta, koje se neće menjati i koje korisnik neće ni videti. I drugo polje USER_ID koji će kontrolisati korisnik i na kome možeš da lakše obezbediš kontinuitet.