Baza de date încetinește după importul inițial: erori în date, fișier Excel și setări de import

Lansarea unui nou punct comercial sau trecerea la un nou program de evidență este întotdeauna însoțită de transferul masiv de date. În loc de săptămâni de introducere manuală, mii de poziții din nomenclator sunt încărcate în câteva minute prin import din Excel. Totuși, chiar în această etapă, înainte de primele vânzări, sistemul poate începe brusc să funcționeze lent, să se blocheze sau să afișeze erori neclare.

Să analizăm cele mai frecvente cauze pentru care baza de date «cedează» la început și modalitățile de remediere.

1. Limitele versiunii gratuite SQL Express: de ce se umple baza

Pentru stocarea datelor în program, în mod implicit se folosește versiunea gratuită Microsoft SQL Server Express. Aceasta este potrivită pentru afacerile mici și mijlocii, dar are limitări tehnice stricte, despre care utilizatorii adesea nu știu la început.

• Limite privind volumul de date. Versiunile SQL Server 2008, 2012, 2014, 2016 și 2017 în ediția Express au o limită strictă pentru dimensiunea bazei de date — maximum 10 GB. (Pentru versiunea foarte veche SQL Server 2005, această limită este de doar 4 GB).

• Limite privind memoria RAM: indiferent de câtă memorie RAM este instalată pe serverul dumneavoastră, versiunea gratuită SQL Express va utiliza cel mult 1,4 GB RAM.

La începutul lucrului cu o bază nouă, importul masiv de produse de obicei nu duce la umplerea bazei SQL. În mod implicit, fotografiile produselor sunt stocate în sistemul de fișiere, nu în interiorul bazei de date, de aceea ele nu ar trebui să mărească rapid dimensiunea fișierului SQL.

Dacă baza a început să funcționeze lent imediat după import, în primul rând merită verificată nu limita SQL Server Express, ci corectitudinea pregătirii fișierului Excel, setările de import și posibilele erori în date: rânduri goale în plus, formate incorecte, duplicate, valori anormale ale cantității sau prețului. Anume astfel de erori afectează mai des stabilitatea bazei la început.

Cum se rezolvă problema:

• Comprimarea bazei (Shrink) nu reduce volumul datelor reale, ci doar poate elibera spațiul neutilizat din fișierul bazei. Aceasta nu corectează erorile de import și nu optimizează datele în sine.

• Curățarea protocoalelor este relevantă în principal pentru bazele vechi, care funcționează de mult timp și au acumulat multe înregistrări în jurnale. Într-o bază nouă, după importul inițial, protocoalele sunt de obicei goale sau aproape goale.

• Mutarea fotografiilor din bază la început nu este, de asemenea, o soluție tipică, deoarece fotografiile produselor sunt stocate implicit în sistemul de fișiere. Acesta este modul recomandat de stocare. Stocarea fotografiilor direct în baza de date este o abordare depășită, care nu ar trebui utilizată.

Prin urmare, dacă sistemul funcționează lent după importul inițial, mai întâi trebuie să verificați fișierul Excel, setările de import, corectitudinea cantităților, prețurilor, codurilor de bare, articolelor și lipsa valorilor anormale în documente.

2. Eroarea «Arithmetic overflow»: capcana codului de bare

Una dintre cele mai grave erori cauzate de factorul uman în timpul recepției inițiale a mărfii sau al inventarierii este scanarea accidentală a codului de bare în câmpul greșit.

  Cauza. Utilizatorul, în locul câmpului «Cod de bare», plasează cursorul în câmpul «Cantitate» sau «Preț» și scanează un cod de bare standard de 13 cifre (de exemplu, 2955650064811). Drept rezultat, programul înregistrează existența produsului într-o cantitate de câteva miliarde de unități. Baza de date nu este proiectată pentru prelucrarea unor astfel de valori matematice în tipurile standard de date (int). Acest lucru duce la o eroare critică: Arithmetic overflow error converting expression to data type int (sau numeric).

Consecințe pentru bază:

• Orice încercare a programului de a recalcula automat costul sau de a închide perioada se blochează complet pe acest produs problematic.

• Un produs cu un astfel de istoric anormal al mișcării (de exemplu, solduri de miliarde) face imposibilă formarea corectă a situațiilor de rulaj.

 Soluție: trebuie să găsiți documentul (factura de intrare sau lista de inventariere) în care codul de bare a fost scanat în locul cantității și să îl editați, indicând valoarea corectă. 

Puteți găsi singur un astfel de produs în formularul «Mișcarea mărfii». Pentru aceasta este suficient să sortați datele după cantitate: pozițiile cu valori anormal de mari vor fi vizibile imediat. După aceea, trebuie să deschideți documentul corespunzător și să corectați cantitatea sau prețul introdus greșit.

3. Collation Conflict: standardele lingvistice ale serverului

Uneori, după instalarea reușită a SQL Server și importul produselor, utilizatorul se confruntă cu o problemă aparent misterioasă: produsele există în bază, dar în formularul «Starea depozitului», atunci când încearcă să aplice un filtru sau o căutare, acestea nu sunt afișate, sau programul afișează o eroare.

 Cauza. Această problemă este legată de Collation (parametrii de sortare) — o setare la nivelul SQL Server, care definește regulile de sortare a caracterelor și standardele lingvistice (de exemplu, Ukrainian_CI_AS sau Cyrillic_General_CI_AS). Dacă parametrii de sortare ai bazei de date nu corespund așteptărilor programului sau setărilor serverului, apare un conflict.

 Soluție. Problema se rezolvă exclusiv la nivelul administrării bazei de date, prin modificarea setărilor Collation pentru un anumit SQL Server sau pentru baza de date însăși.

4. Optimizarea după importul masiv

Procedura de import masiv a mii de produse din Excel necesită o abordare corectă, altfel baza se poate bloca încă în timpul procesului:

• Out of memory. Dacă în documentul Excel utilizatorul a selectat accidental rânduri sau coloane goale până la capătul foii, programul va încerca să prelucreze acest masiv gol uriaș, ceea ce va duce la eroarea de memorie insuficientă (Out of memory).

• Fixarea prețurilor. Dacă la import se activează setarea «Fixați modificarea prețului de achiziție», programul va căuta și va compara prețurile anterioare pentru fiecare produs, ceea ce încetinește critic procesul de încărcare a bazei.

 Acțiune obligatorie după import! Când încărcați simultan într-o bază goală mii de produse noi, SQL Server încă nu știe cum să caute rapid această informație. «Hărțile» sale interne (indexurile) sunt goale sau neactuale. Dacă începeți imediat vânzarea, adăugarea produsului în bon sau deschiderea depozitului se va face foarte lent.

Operațiunea «Restabiliți și reorganizați indexurile și actualizați statisticile» se efectuează de obicei automat în timpul calculului automat nocturn al costului, dacă acest mecanism nu a fost dezactivat forțat.

De aceea, după importul inițial nu este necesar să rulați manual această operațiune de service ca pas obligatoriu. Mai întâi merită să verificați dacă este activat calculul automat al costului și dacă se execută operațiunile nocturne programate. Aceasta recompilă structura de căutare în SQL Server, iar după aceea lucrul cu un nomenclator de mii de poziții devine rapid și stabil.