поискал не нашел
но походу trim в select через oledb из файлов.dbf не работает
проверяли?



Исправлено 1 раз(а). Последнее : alex;, 23.07.20 12:06

смотря какой trim и смотря что от него ожидается. varchar из обычных char полей он сам по себе не сделает, поэтому хвостовые пробелы никуда не денутся.

Поясню
в c#
reader возвращает с пробелами.
т.е. если поле f1 char, то trim делать бессмысленно ?

Достаточно очевидно, поле в рекордсете не может быть переменной длины)))
Потому все приведется к самому длинному.
Либо через cast, либо при обработке результата

Аспид
Достаточно очевидно, поле в рекордсете не может быть переменной длины)))

Учитывая старый ADO спорный - тезис.

alex;
Учитывая старый ADO спорный - тезис.

Как то считал это очевидным. Но возможно и ошибаюсь.

И все же почти уверен, что это так.
Чем может быть рекорсет, как ни некой структурой, у которой, как полагаю, жестко заданы параметры.

Трудно представить себе поле филд в одной записи, длинной 10, а в другой 12



Исправлено 1 раз(а). Последнее : Аспид, 24.07.20 12:38

а varchar?

alex;
Учитывая старый ADO спорный - тезис.

Именно это)))
А варчар, это относительно новая фишка, и способ хранения данных.
Получи выборку варчар с sql сервера на фокс.
Поле будет длинной, самого длинного полученного
Как минимум
И кстати шарп это подтверждает.
Убирать пробелы, надо при обработке конкретного значения поля(если надо)



Исправлено 1 раз(а). Последнее : Аспид, 24.07.20 12:51

или даже запрос из csv без фиксированной длины с разделителями

Аспид

alex;
Учитывая старый ADO спорный - тезис.

Именно это)))
А варчар, это относительно новая фишка, и способ хранения данных.
Получи выборку варчар с sql сервера на фокс.
Поле будет длинной, самого длинного полученного
Как минимум

по-моему это стереотип перешедший из фокса

Так проверь его на шарпе.
Получи конкретное значение, одно. Посмотри что с ним будет.
Потом другое. По одной записи.
Спор то, проверяется за пол часа

да, времени нет и прч...
обязательно проверю

alex;
reader возвращает с пробелами.
т.е. если поле f1 char, то trim делать бессмысленно ?

Поскольку функция trim() это та же самая функция rtrim(), и она обрезает только хвостовые пробелы, а тип поля char предполагает строго фиксированный размер и все строки будут в нём дополнены пробелами до размера поля, то да - применять trim в запросе не имеет абсолютно никакого смысла.
С другой стороны, существует версия VFP OLEDB провайдера от 9-го фокса, где уже есть varchar тип полей (которые не дополняются пробелами справа) и есть функция cast для преобразования типов, в т.ч. позволяющая получит varchar поле, то комбинация cast и rtrim уже не будет являться бессмысленной.
Впрочем и для старых версий при помощи всяких хиртых трюков, например UNION с таблицей нужной структуры, можно добиться чтобы запрос преобразовал это поле в memo - а оно тоже не имеет фиксированного размера и не добивается ненужными пробелами.

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

Игорь, спасибо за ответы.

Я, да, сделал trim шарпе.

Реализовал загрузку фиас из dbf
Две таблицы, пакетами по 100к записей с trim в temp.csv и SqlBulkCopy на обычном компе с ограничением ОП MS SQL 8Гб - 54 минуты.
Если есть возможность взглянуть
- на сколько это "убого" получилось?
github.com

alex;
Игорь, спасибо за ответы.
Я, да, сделал trim шарпе.

Реализовал загрузку фиас из dbf
Две таблицы в ms sql addrobj и house, пакетами по 100к записей с trim в temp.csv и SqlBulkCopy на обычном компе с ограничением ОП MS SQL 8Гб - 54 минуты.
Если есть возможность взглянуть
- на сколько это "убого" получилось?
github.com

это около 80млн записей



Исправлено 1 раз(а). Последнее : alex;, 24.07.20 22:16

alex;
Если есть возможность взглянуть
- на сколько это "убого" получилось?

Зачем тебе это? Устраивает, решает задачу, ну и радуйся
Меньше знаешь - крепче спишь.

Да, вот задумался может на фоксе переписать.
И вызывать bulk через sqlcmd...

или напрямую вместо bulk...

mssql умеет же сам внешние данные через oledb получать.

вот, вот,
подумкаю еще

а код на шарпах может Сергей(SType) потом как-нидь покритикует
...