Интерфейс Online Server

Цитата
Torquader писал(а): Как известно, у вас так и не решена проблема повторяющихся папок. Во-первых, при считывании базы товаров в другую программу нельзя считать содержимое второй папки, так как папка в функциях задаётся именем.

Эти проблемы будут решены: имя каждого раздела в новой версии - уникально, доступ по OLE будет осуществляться с использованием идентификаторов разделов. В новой версии программы также снимаются ограничения на максимальное количество разделов и уровней их вложенности.

Цитата

Torquader писал(а): Но, хотелось бы, чтобы будущая версия была более продумана по части стандартных денйствий. То есть, если уж делается похожей на Windows и использует стандартные действия, то результат должен быть таким же как и у других программ. Потому как чайников обучают именно стандартным действиям. Ну или хотя бы сделать более удобный редактор базы, даже если он будет запускаться отдельно.

Постараемся сделать "стандартные действия" максимально совпадающими с аналогичными в других программах.

Цитата
Torquader писал(а): И основной вопрос - почему формат базы товаров не DBF?

На данный момент для основной базы используется свой формат, который обеспечивает более высокое быстродействие по сравнению с DBF. В момент работы вся база хранится в ОЗУ (на диск сбрасываются только изменения), что позволяет увеличить скорость поиска товара при запросе от ККМ и т.д., но накладывает повышенные требования к объему оперативной памяти (хотя это критично только в случае хранения в базе чеков за несколько десятков смен по нескольким ККМ). OnlineServer v 2.0 в качестве DB Engine будет использовать SQL сервер Firebird, что позволит работать нескольким серверам в сети с одной базой, полностью отвязать отчеты от реализации программных модулей, и т.д. Работа с данными будет возможна посредством новой реализации OLE, импорта/экспорта в текстовые файла и файлы DBF, а также при помощи непосредственного подключения к БД (чтение данных ни к чему не обязывает, а при изменении данных с использованием непосредственного подключения к БД ответственность за целостность и корректность данных будет лежать на разработчике, использующем этот метод работы с базой данных).

Вычитывание данных производится запросами из приложения (за исключением редких случаев), а изменение данных, преимущественно (но не полностью), производится при помощи хранимых процедур.

А это имеет какое-либо принципиальное значение?

Цитата

ping писал(а): В нормальных условиях наверное всеравно, но ведь у нас как всегда... Предположим ОС "зависла", и затем последовала холодная перезагрузка системы и т.д. Просто нормальный SQL сервер незавершенные транзакции откатит и логическая целостность информации должна прийти в норму. Хотя помоему основная задача по максимуму снизить вероятность рассогласования между З-отчетом кассы и таблицей продаж сервера, причем при условии что связь между ккм и компьютером периодически пропадает, на сигналы действуют помехи и т.д.

Действительно, при обрыве коннекта с клиентом (или в другой нештатной ситуации) сервер откатывает все незавершенные этим клиентом транзакции. Время выполнения простых типовых операций на сервере не сильно различается при выполнении их с клиента и при вызове с клиента ХП, которая производит те же действия. А поскольку управление транзакциями в Interbase/Firebird производится только с клиента, то необходимость реализации хранимых процедур, определяется только требованиями к целостности данных (при их изменении) и необходимостью формировать сложные запросы, которые при помощи стандарта SQL реализовать проблематично или их быстродействие "оставляет желать лучшего". Но это лирическое отступление, а вообще я особых проблем не вижу: при запросе от ККМ покупка сразу сохраняется в БД вместе с информацией о ККМ, номере КЛ и номере чека, к которым она относится. Операция выполняется в короткой транзакции. Даже если сервер из-за помех на линии (или по другой причине) не отловит событие закрытия чека (с АМС-200Ф маловероятно, с АМС-100Ф такая вероятность побольше), то при начале набора на данной ККМ следуещего чека, текущий чек попадет в закрытые (или сброшенные) чеки автоматически.

Цитата
ping писал(а): ...и касса давай закорюли показывать и разные символы печатать, пришлось выключить и включить. Короче продажа в компьютер не попала.

Немного непонятно про закорюли... Если происходят сбои в ККМ, то они и являются причиной потери чеков в БД, и решать эту проблему в товароучетном ПО не совсем правильно (точнее, полностью порешать эту проблему на верхнем уровне не получится). Нормальное функционирование системы возможно, как минимум, только при нормальном функционировании каждой его составляющей.

Не совсем так...
В версии сервера 2.0 при возникновении подобных ситуаций будет производится сверка с электронным журналом кассового аппарата, и на основе нее будет приниматься решение о том закрывать или сбрасывать текущий чек. Само собой разумеется, если произошел сбой на ККМ, то 100% гарантию того, что текущий чек попадет туда, куда должен, даже сверка с ЭЖ дать не может (поскольку неизвестны последствия сбоя для ККМ). И конечно этот алгоритм не поможет в том случае, если выдернуть из ККМ кабель и вести продажи свободными суммами. Здесь о корректном товарном учете, понятно, не может быть и речи.