База гальмує після стартового імпорту: помилки в даних, Excel-файлі та налаштуваннях імпорту

Запуск нової торгової точки або перехід на нову програму обліку завжди супроводжується масовим перенесенням даних. Замість тижнів ручного введення, тисячі позицій номенклатури завантажуються за лічені хвилини через імпорт з Excel. Проте саме на цьому етапі, ще до проведення перших продажів, система може несподівано почати гальмувати, зависати або видавати незрозумілі помилки.

Розглянемо найпоширеніші причини, чому база даних «вмирає» на старті, та розберемо способи їх усунення.

1. Межі безкоштовного SQL Express: чому база переповнюється

Для зберігання даних у програмі за замовчуванням застосовується безкоштовна версія Microsoft SQL Server Express. Вона ідеально підходить для малого та середнього бізнесу, але має жорсткі апаратні обмеження, про які користувачі часто не знають на старті.

• Ліміти об'єму даних. Версії SQL Server 2008, 2012, 2014, 2016 та 2017 редакції Express мають жорстке обмеження на розмір бази даних — максимум 10 ГБ. (Для дуже старої версії SQL Server 2005 цей ліміт взагалі становить 4 ГБ).

• Ліміти оперативної пам'яті: Незалежно від того, скільки оперативної пам'яті встановлено на вашому сервері, безкоштовний SQL Express використовуватиме не більше 1,4 ГБ ОЗП.

На старті роботи нової бази масовий імпорт товарів зазвичай не призводить до переповнення SQL-бази. За замовчуванням фотографії товарів зберігаються у файловій системі, а не всередині бази даних, тому вони не повинні швидко збільшувати розмір SQL-файлу.

Якщо база почала гальмувати одразу після імпорту, насамперед варто перевірити не ліміт SQL Server Express, а коректність підготовки Excel-файлу, налаштування імпорту та можливі помилки в даних: зайві порожні рядки, некоректні формати, дублікати, аномальні значення кількості або ціни. Саме такі помилки частіше впливають на стабільність роботи бази на старті.

Як вирішити проблему:

• Стискання бази (Shrink) не зменшує обсяг реальних даних, а лише може звільнити невикористаний простір у файлі бази. Це не виправляє помилки імпорту та не оптимізує самі дані.

• Очищення протоколів актуальне переважно для старих баз, які працюють тривалий час і накопичили багато записів у журналах. У новій базі після стартового імпорту протоколи зазвичай порожні або майже порожні.

• Вивантаження фотографій із бази на старті також не є типовим рішенням, тому що за замовчуванням фотографії товарів зберігаються у файловій системі. Саме такий спосіб зберігання рекомендований. Зберігання фотографій безпосередньо в базі даних — застарілий підхід, який не варто використовувати.

Тому при гальмуванні після стартового імпорту спочатку потрібно перевірити Excel-файл, налаштування імпорту, коректність кількостей, цін, штрихкодів, артикулів і відсутність аномальних значень у документах.

2. Помилка «Arithmetic overflow»: пастка штрихкоду

Однією з найбільш руйнівних помилок людського фактора під час початкового оприбуткування товару або інвентаризації є випадкове сканування штрихкоду не в те поле.

  Причина. Користувач замість поля «Штрихкод» встановлює курсор у поле «Кількість» або «Ціна» і сканує стандартний 13-значний штрихкод (наприклад, 2955650064811). В результаті програма фіксує наявність товару в кількості кількох мільярдів одиниць. База даних не розрахована на обробку таких математичних значень у стандартних типах даних (int). Це призводить до критичної помилки: Arithmetic overflow error converting expression to data type int (або numeric).

Наслідки для бази:

• Будь-яка спроба програми автоматично перерахувати собівартість або закрити період «намертво» зависає на цьому проблемному товарі.

• Товар з такою аномальною історією руху (наприклад, мільярдні залишки) робить неможливим коректне формування обігових відомостей.

 Рішення: необхідно знайти документ (прихідну накладну або відомість інвентаризації), де був відсканований штрихкод замість кількості, та відредагувати його, вказавши правильне значення. 

Знайти такий товар можна самостійно у формі «Рух товару». Для цього достатньо відсортувати дані за кількістю: позиції з аномально великими значеннями будуть помітні одразу. Після цього потрібно відкрити відповідний документ і виправити некоректно внесену кількість або ціну.

3. Collation Conflict: мовні стандарти сервера

Іноді після успішного встановлення SQL Server та імпорту товарів користувач стикається з містичною проблемою: товари є в базі, але на формі «Стан складу» при спробі застосувати фільтр або пошук вони не відображаються, або програма видає помилку.

 Причина. Ця проблема пов'язана з Collation (параметрами сортування) — налаштуванням на рівні SQL Server, яке визначає правила сортування символів та мовні стандарти (наприклад, Ukrainian_CI_AS або Cyrillic_General_CI_AS). Якщо параметри сортування бази даних не збігаються з очікуваннями програми або налаштуваннями самого сервера, виникає конфлікт.

 Рішення. Проблема вирішується виключно на рівні адміністрування бази даних шляхом зміни налаштувань Collation для конкретного SQL Server або самої бази даних.

4. Оптимізація після масового імпорту

Сама процедура масового імпорту тисяч товарів з Excel вимагає правильного підходу, інакше база може зависнути ще в процесі:

• Out of memory. Якщо в Excel-документі користувач випадково виділив порожні рядки або стовпці до самого кінця аркуша, програма спробує обробити цей гігантський порожній масив, що призведе до помилки нестачі пам'яті (Out of memory).

• Фіксація цін. Якщо при імпорті увімкнути налаштування «Фіксувати зміну ціни закупівлі», програма буде шукати та порівнювати попередні ціни для кожного товару, що критично уповільнює процес завантаження бази.

 Обов'язкова дія після імпорту! Коли ви одномоментно завантажили в порожню базу тисячі нових товарів, SQL Server ще не знає, як швидко шукати цю інформацію. Його внутрішні «карти» (індекси) порожні або неактуальні. Якщо відразу почати продавати, додавання товару в чек або відкриття складу буде відбуватися дуже повільно.

Операція «Відновити та реорганізувати індекси та оновити статистики» зазвичай виконується автоматично під час нічного автоматичного розрахунку собівартості, якщо цей механізм не був вимкнений примусово.

Тому після стартового імпорту не потрібно запускати цю сервісну операцію вручну як обов’язковий крок. Спочатку варто перевірити, чи увімкнений автоматичний розрахунок собівартості та, чи виконуються нічні регламентні операції. Це перекомпілює структуру пошуку в SQL Server, і після цього робота з багатотисячною номенклатурою стане швидкою та стабільною.