csv и загрузка в поле с типом время

[Arahnid]

Как можно загрузить из csv поле со временем.
Формат 9:00 в поле с типом timeofday грузится как 0, хотя и на просмотре в настройках это 9. Минуты вообще не получается увидеть.

[EVGL]

В AX время - это целочисленные данные, число секунд от полуночи. От этого и отталкивайтесь.

[KiselevSA]

Берем дробную чась даты, умножаем на 86400 (24*60*60), округляем до целого и пишем полученное значение в csv, а потом уже грузим в поле времени в Ax.

[gl00mie]

По-моему, тот или иной импорт (коих может быть очень много) должен быть максимально абстрагирован от подобных заморочек с преобразованием типов - в данном случае из строки во время. Подобные заморочки должны быть вынесены в некий специализированный класс, и кое-что уже готовое даже есть: Класс для преобразования значений между различными значимыми типами

[EVGL]

Практически любой импорт - индивидуальная вещь, а то и вещь для однократного использования. Редко бывает выгода от абстракций.

[gl00mie]

Не могу согласиться У меня как-то получилось так, что куча импортов из файлов работает в конечном счете с той или иной таблицей (пусть и временной), под такой случай получилось несколько базовых классов:

• абстрактный импорт из файла на стороне клиента: по принципу работы RunBase.prompt() умеет переключаться на клиента для считывания данных в Map, который затем затягивается на сервер для дальнейшей обработки;
• на базе него абстрактный импорт полей записи; класс-наследник должен определиться с тем, в какую таблицу какие поля из каких номеров "колонок" считывать, какие поля обязательны к заполнению (если они окажутся пустыми, импорт на стороне клиента завершится), а также (та-да!) переопределить метод, считывающий из указанной колонки значение указанного базового типа. Класс, в свою очередь, через Dict-классы определяет, как какое поле считывать, до скольки символов обрезать строки, выполняет все сопутствующие проверки, кэширует нужные метаданные для ускорения и т.п.
• на базе него абстрактный класс импорта записей: тут добавляется кое-какая логика по пред- и постобработке записей, корректировке считанных значений полей (скажем, валютные суммы могут округляться с выводом соотв. предупреждений), сохранении считанных записей в RecordSortedList для выявления дубликатов и/или обработки в нужном порядке.

Плюс к этому еще есть класс-наследник, реализующий на базе этого всего импорт из файлов Excel. Так вот, обычно импорт в ту или иную конкретную таблицу либо реализует целиком всю остальную логику, т.е. фактически указывает, что в такую-то таблицу надо считать такие-то поля, а в остальном просто обрабатывает считанные табличные записи, либо разбивается на два класса: некий, опять же, абстрактный импорт для той или иной таблицы (обычно это строки журналов) и на базе него - уже некий обработчик, скажем, для того или иного типа журналов.
За счет этого:

• оптимизируется клиент-серверное взаимодействие, вся основная работа, все "тяжелые" проверки производятся на сервере;
• легко и просто ловится "конец файла" (скажем, в Excel-файлах пользователи любят протягивать значения ряда колонок до самого низа, хотя импортят 10-20 строк, а так нет значений обязательных полей - значит, пора закругляться);
• в каждом новом импорте можно использовать кучу готового проверенного кода и абстрагироваться от того, откуда или как считываются данные. К примеру, импорт строк журналов ГК из Excel изначально работал через ADO, потом меня забодало бороться с "особенностями" последнего, и я его переписал на SysExcel, а того, в свою очередь, с COM на .NET - все остальные импорты, работающие со строками журналов ГК, при этом никак затронуты не были, но начали работать "на новых рельсах".

Но это все, конечно, - из разряда импортов, используемых каждый день; однако, даже в тупых джобах, лопатящих контейнеры, полученные из AsciiIo, хочется абстрагироваться от таких вот заморочек, хочется не придумывать в ндцатый раз, как корректно считать из файла значение типа enum и т.п.