Стоит MySQL 5.0
Делаю ODBC коннект с Ms SQL server.

При вставке в таблицу данных получаю:

The number of failing rows exceeds the maximum specified

При этом, в одной строке явно меньше 8 килобайт. Какие-то жалкие байты.

Типы вставляемых данных вполне соответствуют структуре таблицы MySQl.

Версия ODBC 3.51 (версия 5.0 не правильно отображает названия баз).

Пробовались различные настройки ODBC (Don't Optimize Column Width, Return Matching Rows, Allow Big Results и другие). Менялся только тип ошибки, при Force Use of Named Pipes например стояла неизвестная ошибка без кода.

Кто что может предложить по решению?

[quot 4m@t!c]Сам запрос покажите?
Кхм.

SELECT distinct
o_p.ID ID,
Extract(YEAR From o_b.plan) YEAR_,
Regions.NAME Region,
Regionpl.name RegPl,
Places.TOWNNAME Town,
o_p.NAME Name,
Places.placest PlaceSt,
Places.street Street,
BUILDINTENT.Name BuildingT,
Case When Extract(Month From o_b.plan)=1 Then "X" Else " " End a1,
Case When Extract(Month From o_b.plan)=2 Then "X" Else " " End a2,
Case When Extract(Month From o_b.plan)=3 Then "X" Else " " End a3,
Case When Extract(Month From o_b.plan)=4 Then "X" Else " " End a4,
Case When Extract(Month From o_b.plan)=5 Then "X" Else " " End a5,
Case When Extract(Month From o_b.plan)=6 Then "X" Else " " End a6,
Case When Extract(Month From o_b.plan)=7 Then "X" Else " " End a7,
Case When Extract(Month From o_b.plan)=8 Then "X" Else " " End a8,
Case When Extract(Month From o_b.plan)=9 Then "X" Else " " End a9,
Case When Extract(Month From o_b.plan)=10 Then "X" Else " " End a10,
Case When Extract(Month From o_b.plan)=11 Then "X" Else " " End a11,
Case When Extract(Month From o_b.plan)=12 Then "X" Else " " End a12,
Masttypes.MAST_TYPE MastType,
Places.MAST_HEIGHT MastHeight,
Mast_owners.NAME MastOwner,
bts.bts_stage Е_Date,
Extract(Day From o_b.plan)||'.'||Extract(Month From o_b.plan)||'.'||Extract(Year From o_b.plan) P_Date,
Extract(Day From o_b.STARTD)||'.'||Extract(Month From o_b.STARTD)||'.'||Extract(Year From o_b.STARTD) Start_D,
cast('NOW' as date) Data_export
from obj o_p
left join places on
o_p.objid = places.objid and
places.current_rec = 'T'
left join BUILDINTENT Buildintent on
(PLACES.BUILDINTENTID = Buildintent.BUILDINTENTID)
left join MASTTYPES masttypes on
(PLACES.MAST_TYPEID = Masttypes.MAST_TYPEID)
left join MAST_OWNERS Mast_owners on
(PLACES.MAST_OWNERID = Mast_owners.MAST_OWNERID)
left join REGIONS Regions
ON (PLACES.REGIONSID = Regions.REGIONSID)
left join REGIONPLANSYS Regionplansys on
(PLACES.REGIONPLANSYSID = Regionplansys.REGIONPLANSYSID)
join obj o_b on
o_p.objid = o_b.belongtoid and
o_b.objtypeid = 2
left join bts on
o_b.objid = bts.objtid and
bts.current_record = 'T'
where o_p.objecttypeid = 1
order by RegPl, Plan_D

Вся штука в том, что сам этот SQL-запрос не имеет никакого значения.

Он прекрасно экспортит данные собственно в MS SQL, в CSV, в TXT, в XLS,
куда хотите.

Вот эти даннные в MySQL уже не получается экспортировать.
Вот где загвоздка!

[quot maXmo]что-то я не вижу факта вставки. Один сплошной селект.

Кхм. Вставку делает DTS.
Select, который тут вы видите -- это source.
Затем выбираем Destination table, Transformations -- из каких колонок куда, и всё.
Так оно работает по замыслу Microsoft.

[quot 4m@t!c]ODBC и MySQL - это не замысел Майкрософта.
Я имел ввиду ДТС и весь этот интерфейс в целом.

maXmoтакое ощущение, что конфликт в данных, а сообщение об ошибке исходит не от мускля, а от вставляльщика. Возможно, поле ID в мускле объявлено как auto_increment и при попытке в него что-нить вставить возникает ошибка; когда вставляльщику не удаётся вставить определённое кол-во строк, он выдаёт ошибку. Попробуй убрать из таблицы auto_increment и повторить.

Так оно и есть, попробовал убрать auto_increment. Результат не изменился.
Битые 2 дня копаюсь с настройками ODBC (их там 4 вкладки). 0 результатов.

Дошёл до цепочки Interbase -> MSSQL table -> XLS -> CSV.
Всё пашет на ура на всех этапах.

Когда же какой-либо из этих промежуточных этапов пытаешься в MySQL воткнуть -- всё. Всё встаёт с той-самой ошибкой.

erdn maXmoтакое ощущение, что конфликт в данных, а сообщение об ошибке исходит не от мускля, а от вставляльщика. Возможно, поле ID в мускле объявлено как auto_increment и при попытке в него что-нить вставить возникает ошибка; когда вставляльщику не удаётся вставить определённое кол-во строк, он выдаёт ошибку. Попробуй убрать из таблицы auto_increment и повторить.

Так оно и есть, попробовал убрать auto_increment. Результат не изменился.
Битые 2 дня копаюсь с настройками ODBC (их там 4 вкладки). 0 результатов.

Дошёл до цепочки Interbase -> MSSQL table -> XLS -> CSV.
Всё пашет на ура на всех этапах.

Когда же какой-либо из этих промежуточных этапов пытаешься в MySQL воткнуть -- всё. Всё встаёт с той-самой ошибкой.

Забыл написать. Есть один сильно кривой способ.
В phpMyAdmin'е самой распоследней версии,
перенастроенном на работу с CP1251 по умолчанию,
когда выбираешь импорт есть режим CSV load data.
Вот там (и только там) он (сгенерённый CSV) вставляется.
Но, код запроса в этом режиме не выдаётся...
Подозреваю, что это что-то вроде:

LOAD DATA LOCAL INFILE 'Путь к csv' INTO TABLE `table_name` FIELDS TERMINATED BY ';' ENCLOSED BY '"' ESCAPED BY '\\' LINES TERMINATED BY '\r\n' IGNORE 1 LINES (

`ID` , `YEAR`, ...
)

но, именно такой запрос сообщает о вставке почему-то именно 1 срочки данных, а по факту ничего не вставляется....

[quot VERS]Проверьте индексы в таблице, судя по всему в них дело.

Извиняюсь, за тупой вопрос, но
что вы имеете ввиду????