Databáza sa po úvodnom importe spomalí: chyby v údajoch, súbore programu Excel a nastaveniach importu

Spustenie novej obchodnej prevádzky alebo prechod na nový evidenčný program je vždy spojený s hromadným prenosom údajov. Namiesto týždňov ručného zadávania sa tisíce položiek nomenklatúry nahrajú za niekoľko minút prostredníctvom importu z Excelu. Práve v tejto fáze, ešte pred prvými predajmi, však môže systém nečakane začať spomaľovať, zamŕzať alebo zobrazovať nejasné chyby.

Pozrime sa na najčastejšie dôvody, prečo databáza «zlyháva» hneď na začiatku, a rozoberme si spôsoby ich odstránenia.

1. Limity bezplatného SQL Express: prečo sa databáza zapĺňa

Na ukladanie údajov v programe sa predvolene používa bezplatná verzia Microsoft SQL Server Express. Je vhodná pre malé a stredné podnikanie, má však prísne technické obmedzenia, o ktorých používatelia na začiatku často nevedia.

• Limity objemu údajov. Verzie SQL Server 2008, 2012, 2014, 2016 a 2017 edície Express majú prísne obmedzenie veľkosti databázy — maximálne 10 GB. (Pre veľmi starú verziu SQL Server 2005 je tento limit iba 4 GB).

• Limity operačnej pamäte: bez ohľadu na to, koľko operačnej pamäte je nainštalované na vašom serveri, bezplatný SQL Express použije maximálne 1,4 GB RAM.

Na začiatku práce s novou databázou hromadný import tovarov zvyčajne nespôsobuje zaplnenie SQL databázy. Fotografie tovarov sa predvolene ukladajú do súborového systému, nie priamo do databázy, preto by nemali rýchlo zväčšovať veľkosť SQL súboru.

Ak sa databáza začala spomaľovať hneď po importe, v prvom rade sa oplatí skontrolovať nie limit SQL Server Express, ale správnosť prípravy Excel súboru, nastavenia importu a možné chyby v údajoch: nadbytočné prázdne riadky, nesprávne formáty, duplicity, anomálne hodnoty množstva alebo ceny. Práve takéto chyby častejšie ovplyvňujú stabilitu práce databázy na začiatku.

Ako vyriešiť problém:

• Zmenšenie databázy (Shrink) neznižuje objem reálnych údajov, môže iba uvoľniť nevyužitý priestor v databázovom súbore. Neopravuje chyby importu ani neoptimalizuje samotné údaje.

• Čistenie protokolov je aktuálne najmä pre staršie databázy, ktoré fungujú dlhý čas a nahromadili veľa záznamov v denníkoch. V novej databáze po úvodnom importe sú protokoly zvyčajne prázdne alebo takmer prázdne.

• Presúvanie fotografií z databázy na začiatku tiež nie je typickým riešením, pretože fotografie tovarov sa predvolene ukladajú do súborového systému. Práve tento spôsob ukladania je odporúčaný. Ukladanie fotografií priamo do databázy je zastaraný prístup, ktorý sa neodporúča používať.

Preto pri spomalení po úvodnom importe treba najskôr skontrolovať Excel súbor, nastavenia importu, správnosť množstiev, cien, čiarových kódov, artiklov a neprítomnosť anomálnych hodnôt v dokladoch.

2. Chyba «Arithmetic overflow»: pasca čiarového kódu

Jednou z najničivejších chýb ľudského faktora počas počiatočného príjmu tovaru alebo inventarizácie je náhodné naskenovanie čiarového kódu do nesprávneho poľa.

  Príčina. Používateľ namiesto poľa «Čiarový kód» umiestni kurzor do poľa «Množstvo» alebo «Cena» a naskenuje štandardný 13-miestny čiarový kód (napríklad 2955650064811). Výsledkom je, že program zaznamená tovar v množstve niekoľkých miliárd kusov. Databáza nie je určená na spracovanie takýchto matematických hodnôt v štandardných dátových typoch (int). To vedie ku kritickej chybe: Arithmetic overflow error converting expression to data type int (alebo numeric).

Dôsledky pre databázu:

• Akýkoľvek pokus programu automaticky prepočítať obstarávaciu cenu alebo uzavrieť obdobie sa na tomto problematickom tovare úplne zasekne.

• Tovar s takouto anomálnou históriou pohybu (napríklad miliardové zostatky) znemožňuje správne vytvorenie obratových výkazov.

 Riešenie: je potrebné nájsť doklad (príjmový doklad alebo inventarizačný výkaz), v ktorom bol čiarový kód naskenovaný namiesto množstva, a upraviť ho zadaním správnej hodnoty. 

Takýto tovar možno nájsť samostatne vo formulári «Pohyb tovaru». Stačí zoradiť údaje podľa množstva: položky s anomálne veľkými hodnotami budú okamžite viditeľné. Potom treba otvoriť príslušný doklad a opraviť nesprávne zadané množstvo alebo cenu.

3. Collation Conflict: jazykové štandardy servera

Niekedy sa po úspešnej inštalácii SQL Server a importe tovarov používateľ stretne so zvláštnym problémom: tovary sú v databáze, ale vo formulári «Stav skladu» sa pri pokuse o použitie filtra alebo vyhľadávania nezobrazujú, prípadne program zobrazí chybu.

 Príčina. Tento problém súvisí s Collation (parametrami triedenia) — nastavením na úrovni SQL Server, ktoré určuje pravidlá triedenia znakov a jazykové štandardy (napríklad Ukrainian_CI_AS alebo Cyrillic_General_CI_AS). Ak sa parametre triedenia databázy nezhodujú s očakávaniami programu alebo nastaveniami samotného servera, vzniká konflikt.

 Riešenie. Problém sa rieši výlučne na úrovni administrácie databázy zmenou nastavení Collation pre konkrétny SQL Server alebo samotnú databázu.

4. Optimalizácia po hromadnom importe

Samotný postup hromadného importu tisícov tovarov z Excelu si vyžaduje správny prístup, inak môže databáza zamrznúť ešte počas procesu:

• Out of memory. Ak používateľ v Excel dokumente omylom označí prázdne riadky alebo stĺpce až po samotný koniec hárka, program sa pokúsi spracovať tento obrovský prázdny rozsah, čo povedie k chybe nedostatku pamäte (Out of memory).

• Fixácia cien. Ak sa pri importe zapne nastavenie «Fixovať zmenu nákupnej ceny», program bude vyhľadávať a porovnávať predchádzajúce ceny pre každý tovar, čo kriticky spomalí proces nahrávania databázy.

 Povinná akcia po importe! Keď naraz nahráte do prázdnej databázy tisíce nových tovarov, SQL Server ešte nevie, ako rýchlo vyhľadávať tieto informácie. Jeho vnútorné «mapy» (indexy) sú prázdne alebo neaktuálne. Ak hneď začnete predávať, pridanie tovaru do účtenky alebo otvorenie skladu bude prebiehať veľmi pomaly.

Operácia «Obnoviť a reorganizovať indexy a aktualizovať štatistiky» sa zvyčajne vykonáva automaticky počas nočného automatického výpočtu obstarávacej ceny, ak tento mechanizmus nebol násilne vypnutý.

Preto po úvodnom importe netreba spúšťať túto servisnú operáciu ručne ako povinný krok. Najskôr sa oplatí skontrolovať, či je zapnutý automatický výpočet obstarávacej ceny a či sa vykonávajú nočné plánované operácie. Tým sa prekompiluje vyhľadávacia štruktúra v SQL Server a potom bude práca s mnohotisícovou nomenklatúrou rýchla a stabilná.