F18

evo jednog indeksa primjera radi:

CREATE INDEX kalk_kalk_id1 ON fmk.kalk_kalk(idfirma, idvd, brdok, rbr, mkonto, pkonto);

odabrao sam ova polja jer ona jedinstveno određuju svaku stavku kalk-a

kod povlačenja baze kažem:

select ... from order by idfirma, idvd, brdok, rbr, mkonto, pkonto LIMIT ... OFFSET ...

sada znam da će se tabela na klijentskoj strani ispravno restaurirati (vidi vezni ticket)

primary key kalk_kalk

idfirma, idvd, brdok, rbr

uvesti primarni ključ kao gore jer to jednoznačno određuje kalk zapis.

ja sam sada u kalk_kalk i kalk_doks radi testa napravio primary ključeve

ALTER TABLE fmk.kalk_kalk ADD PRIMARY KEY (idfirma, idvd, brdok, rbr);
ALTER TABLE fmk.kalk_doks ADD PRIMARY KEY (idfirma, idvd, brdok);

na test1 bazi je tu bilo problema jer je mala milijarda 16-ki u kalk-u bila sa duplim ključem, ono redni broj 8 se pojavljuje dva puta itd...

pa sam na kraju uradio brisanje dokumenata "16" sa servera i nakon toga uspio ovo napraviti.

Ovo treba napraviti u kreiranju ovih tabela u fmk paketu.

Bit će problema u importu podataka, jer ovih grešaka je milijarda vjerovatno.

nakon ovoga, kada sam pokušao ažurirati dupli dokument dobio sam upozorenje i zaustavljen sam

dakle, ova provjera postoji i u samom f18 putem dbf-ova a ima i na pg serveru

ALTER TABLE fmk.kalk_kalk ADD PRIMARY KEY (idfirma, idvd, brdok, rbr);

pa dodaj još koje polje koje će ti obezbjediti jedinstvenost

u fmk paket dodao da se kreiraju i

KALK

• kalk_doks
• kalk_kalk

FAKT

• fakt_fakt
• fakt_doks
• fakt_doks2
• fakt_ugov
• fakt_rugov
• fakt_gen_ug
• fakt_gen_ug_p

sa svim svojim pripadajućim indeksima i grantovima

https://github.com/knowhow/fmk/commit/05476fcd6e5b7027b1111f5f312874398bb4b7c1

naravno, ovo kreiranje će raditi kada uzmemo novu čistu bazu i instaliramo fmk paket

i upravo sam to testirao kod sebe lokalno, napravio novu bazu test_fmk i ubacio u2 i fmk paket i napravio mi je željene tabele i sve indekse i dao sve privlegije potrebne..