[ vekica @ 16.09.2004. 03:08 ] @
da to je problem. naime ja korisniku prikazujem sve podatke iz baze osim primarnog kljuca. a njega generisem kao int. pa sam dodao metodu koja prilikom dodavanja novog elementa samo povecava prim. kljuc za jedan. tipa i++

logicno pitanje i sami pretpostavljate. kada obrisem element moram da sve id- ove (kljuceve) pomerim na levo. e tu je moj problem. kako se to radi jer ja nemogu da pristupim toj koloni "id".

jos da spomenem da podatke iz data seta posle prikazujem u list viewu.

cini mi se da mi je koncept los ali namerno nisam hteo da koristim data grid kontrolu

Pozdrav pametni ljudi
[ jablan @ 16.09.2004. 07:25 ] @
Ako sam te dobro razumeo, ti hoćeš da menjaš ID-jeve drugim slogovima kad obrišeš neki slog da ne bi imao "rupa" u redosledu vrednosti ID-ja? Zašto?
[ vekica @ 17.09.2004. 00:07 ] @
da dobro si me razumeo. pa ako ne uradim to i moja baza krene da raste sta se desava: posle svakog generisanog novog elementa meni se id povecava za jedan. tako da bi (za vrednost int) ja mogao da unesem 42... elemenata. sto je za moju bazu ok. ali ukoliko bih i brisao neke elemente i ponovo dodavao taj broj bi bio znatno manji(jer bi id jednostavno prekoracio int). moglo bi se reci da bi moj id ustvari bio nesto poput = broj novih elemenata - broj elem. koji su dodati posle brisanja poslednjeg elem. recimo
1 2 3 4 5 //pa brisanje
1 3 4 5
1 3 4 5 6 //dodavanje novog. i time bi veoma brzo: index out of range

ali resio sam:

private void UrediPrimaryKeys(int indexUListi) //idexUListi = index u ListView
{
for (int i = indexUListi; i < dataset.Tables["tabelaListaKontakata"].Rows.Count; i++)
{
int x = Convert.ToInt32(dsImenikIMD.Tables["tabelaListaKontakata"].Rows ["id"]) - 1;
dsImenikIMD.Tables["tabelaListaKontakata"].Rows["id"] = x;
}
}
[ jablan @ 17.09.2004. 07:53 ] @
Citat:
vekica: veoma brzo: index out of range

Index out of range? Pričaš o .NET-u? Tip int u .NETu je označeni tridesetdvobitni. To znači da imaš 2,147,483,647 INSERT-a fore pre nego lupiš u plafon. Više od dve milijarde. Milijarde. To jeste da je manje od količine dolara koje poseduje Bil Gejts, ali je za konvencionalno indeksiranje slogova sasvim dovoljno. Ili možda grešim?
[ spartak @ 17.09.2004. 07:54 ] @
Ne znam ko je i zasto obrisao moju prethodnu poruku, ali:

Znas li da si upravo ruinirao performanse programa? To mozda nece odmah da se vidi ali kad budes imao dosta zapisa u bazi i malo jaci saobracaj brisanja pisanja, tvoj program ce pola vremena rada samo bazu da reindeksira.

Sta ces sa rekordima iz tabela koje ces eventualno kljucevima da povezes sa ovom tabelom? I njih ces da reindeksiras po novim parent kljucevima?

Sta ces sa Cross Reference tabelama? Njih bolje onda samo u memoriji i da drzis - posto ce da budu usijane.

Jos jednom da ponovim savet, i da se nadam da nece da me brishu ponovo: "Nemoj da diras primarne kljuceve, oni su jedinstveni identitet nekog rekorda".
[ havramm @ 17.09.2004. 08:30 ] @
Citat:
spartak: Ne znam ko je i zasto obrisao moju prethodnu poruku
Ja sam je obrisao zbog toga što je bila totalno nejasna
Citat:
nemoj da pregupisavasindekse.
ili već nešto slično.

U svakom slučaju sam naveo razlog brisanja i trebalo bi da si dobio povratni mail.
[ dusans @ 17.09.2004. 10:00 ] @
Najbolja varijanta ti je da ne petljas sa promenom vrednosti primarnog kljuca sto je kod velikog broja slogova vrlo sporo (zamisli da imas sto hiljada redova i obrises prvi znaci ide ti sto hiljada apdejtova na baze plus sto taj apdejt moze da povuce i reindeksiranje kaskadne apdejtove na child tabelama...) vec da kad ucitas podatke prosto dodas novu kolonu prodjes kroz sve redove i upises u njoj vrednosti 1, 2, 3, 4, ....