Pozdrav,

u att šaljem primjer multipliciranog zapisa carina u šifrantu idenata panel carine i ostala davanja.

Lp
Bojana

Pozdrav,

Do ovoliko zapisa dolazi zbog narušenog referencijalnog integriteta, koji je porušen na svim bazama (centrali i svim lokacijiama). Kad je referencijalni integritet porušen tada je moguće da se u bazu zapisuju isti zapisi i zato se nagomilalo toliko istih (praznih zapisa). Također kod narušenog referencijalno integriteta moguće je brisati neke zapise koje u normalnim okolnostima program ne bi dopustio brisati.

Zbog toga je nužno na bazama popraviti referencijalni integritet, to možete napraviti pomoću alata u Administratorskoj konzoli / Baza Podataka / Kontrola referencijalnog integriteta.
Ono što se neće moći popraviti na ovaj način (automatizmom) morat ćete popraviti ručno.

Nakon što se popravi referencijalni integritet preporučljivo je još jednom baze nadograditi na isti build.

Do ovakog stanja je najvjerojatnije došlo zbog toga što baze nisu bile redovito nadograđivane, bile su velike pauze između nadogradnji (i po 8 mjeseci) i radio se veliki skok između buildeva. Da bi se to izbjeglo potrebno je redovitije nadograđivati baze i poslje svake nadogradnje provjeriti kakvo je stanje sa referencijalnim integritetom.

Već ranije u usmenoj komunikaciji utvrdili smo da OTOS prijenos spor ( a e-mail ne prihvaća datoteke) zbog količine podataka koje treba prenjeti. Npr. tabela the_setitemexice imala je više od 260 000 zapisa sa vrijednostima 0 ili npr. Tabela the_SetItemCosts imala je 8900 zapisa od toga unikatnih samo 232. To toga je dolazilo upravo zbog narušenog referencijalnog integriteta.

Da bi riješili spori prijenos pomaknuo se datum sinkronizacije na dan zadnje uspješenje sinkronizacije i obrisale su se prazni zapisi u tabeli the_setitemexice, sa promjenom sistemskog datume.
Za lakše traženje tabela koje kod prijenosa Otosom imaju puno pozicija programer je pripremio SQL korak:

create table _lhe_NumberOfRowsForTables
(
tabela varchar(50),
kolone int
)
 
 
declare @cTable varchar(50)
DECLARE crNumberOfRows CURSOR FOR
select TABLE_NAME from information_schema.tables
where TABLE_TYPE = `BASE TABLE`
OPEN crNumberOfRows
FETCH NEXT FROM crNumberOfRows INTO @cTable
WHILE @@FETCH_STATUS=0
BEGIN
insert into _lhe_NumberOfRowsForTables (tabela,kolone)
select @cTable,rows from sysindexes where indid in (0,1)
and id IN (object_id(@cTable))
order by rows desc
FETCH NEXT FROM crNumberOfRows INTO @cTable
END
--------oćistim
CLOSE crNumberOfRows
DEALLOCATE crNumberOfRows


SQL korak možete naći i u privitku tako da nemate problema sa kosim navodnicima.

VAŽNO!!!
Kod tabela the_SetItemCosts i the_SetItemExcise obratite veliku pažnju ako se veličina zapisa povećava sa prijenosima. Napravite kontrolu poslje prijenosa.
Ako se količina zapisa povećava, javite.

Također, napravite i shrink baze, jer npr. centralana baza je nepotrebano velika 1GB, poslje shrinka ona se samnji na oko 0,5GB.

Pozdrav,

poslje nadogradnje obvezno se provjeri log nadogradnje, da li ima grešaka. Log nadogradnje javi i greške vezane za referencijalni integritet.

A u nekim slučajevim kada je velika razlika među buildevima dobro je napraviti prvo nadogradnju na neki build između, pa zatim na zadnji.