DTS портит данные типа sql

← →
BPK (2004-05-13 09:53) [0]

У меня в одной из колонок таблицы содержатся данные типа sql_variant, поскольку данные должны быть разного типа.
Всё бы ничего, но после копирования таблиц с отладочного сервера на рабочий при помощи DTS, вместо правильных данных в этом столбце возникает мусор.
Как бороться?

← →
BPK (2004-05-13 23:27) [1]

Дополнение:

При применении запроса типа

update mt1 set mt1.value=mt2.value
from bd1..mytable mt1
inner join bd2..mytable mt2 on mt1.[id]=mt2.[id]

Данные в поле value (sql_variant) базы данных bd1 восстанавливаются, но это происходит в пределах одного сервера, а мне нужно скопировать на другой.
Есть идеи?
Может быть кто-нибудь из вас подскажет, как использовать в T-SQL-запросе две таблицы из двух баз данных на двух разных СЕРВЕРАХ?

← →
sniknik © (2004-05-14 08:43) [2]

по основному вопросу надо пробовать но неохота и серверов много дома нет ... может на работе если время будет.
кстати чтобы проверить нужно больше данных (а то не исключено что у меня все будет нормально)

> Может быть кто-нибудь из вас подскажет, как использовать в T-SQL-запросе две таблицы из двух баз данных на двух разных СЕРВЕРАХ?

Bol.Examples
This example accesses data from a table on another instance of SQL Server.

SELECT *
FROM OPENDATASOURCE(
"SQLOLEDB",
"Data Source=ServerName;User ID=MyUID;Password=MyPass"
).Northwind.dbo.Categories

← →
BPK (2004-05-14 09:42) [3]

>OPENDATASOURCE...
Спасибо, всё ОК.

>чтобы проверить нужно больше данных (а то не исключено что у
>меня все будет нормально

А данные такие:
имеется корпоративный MSSQL-сервер плюс MSDE на локальной машине.
Я формировал структуру и отлаживал БД на MSDE, а затем, как обычно, решил перенести её на рабочий сервер с помощью Data Transformation Services. Всё прошло нормально, за исключением одного - тот столбец, который хранит данные sql_variant, содержит мусор.

То же самое происходит и при локальном копировании в пределах одного SQL-сервера.

Я попробовал дома - та же петрушка. Что интересно: нигде во всём Интернете я не нашёл ни одного упоминания о данной проблеме.

← →
bushmen © (2004-05-14 09:45) [4]

2BPK:
А на http://www.sql.ru был?

← →
Nikolay M. © (2004-05-14 09:50) [5]

> BPK (14.05.04 09:42) [3]

Detach ее на рабочем, потом Attach на рабочем.

← →
BPK (2004-05-14 09:55) [6]

Помог такой запрос:

update mt1 set mt1.val=mt2.val
from Таблица as mt1
inner join OPENDATASOURCE("SQLOLEDB","Data Source=Сервер;User ID=Узер;Password=Пароль").База.dbo.Таблица as mt2
on mt1.[id]=mt2.[id]

← →
BPK (2004-05-14 09:57) [7]

P.S. В понедельник посмотрим, что будет с БД после автоматического копирования на другой сервер.

← →
sniknik © (2004-05-14 10:47) [8]

вот именно так и думал... все отработало без ошибок, поле sql_varian значения для теста /10(числом), и строки "Test Str", "Test Русский".

> А данные такие:
это не то. что содержал что получилось? если был русский текст то какой язык установлен у сервера у юзера. с какими параметрами перенос. в общем нужно то что помогло бы сравнить и сэмулировать глюк.

а вообще, действительно если базу надо перенести всю то > Nikolay M. © (14.05.04 09:50) [5]

← →
BPK (2004-05-14 12:31) [9]

>если базу надо перенести всю

Только несколько таблиц

>что содержал что получилось?

================================
Было
================================
К155ЛА3
К155ЛА3
3
NULL
0
2
0
КР1518ВЕ1-004
КР1518ВЕ1
200
45
-1
3
4
-1
55
Эксперимент
Большоооой эксперимент
25
3
0
0
48
К50-16
К50-16
5
0.44
6
2

0

================================
Стало
================================
1
1

NULL

1
1

яяяя

яяяя

-:A?5@8<5=B
>;LH>>>>9

5
5

)\ЏВх(Ь?

← →
BPK (2004-05-14 12:34) [10]

Причём заметь, что первые два значения - текст, затем - целое число и т.д. Т.е. типы разные.

← →
Nikolay M. © (2004-05-14 12:39) [11]

А настройки серверов одинаковы в плане COLLATION-ов?
text, ntext, image, timestamp, часом, в тестовую базу не пихались?

← →
BPK (2004-05-14 12:59) [12]

Выдержка из документации (специалоно для Nikolay M. ©):

The only types of values that cannot be stored using sql_variant are text, ntext, image, timestamp, and sql_variant.

Раз в доке так написано, то я и не пытался пихать такие данные в sql_variant.
В cast использую int,float,money,nvarchar,datetime,bit.
Пока реально использовал только int,float,nvarchar.

← →
BPK (2004-05-14 13:00) [13]

>А настройки серверов одинаковы в плане COLLATION-ов?

Где посмотреть?

← →
Nikolay M. © (2004-05-14 13:15) [14]

> Выдержка из документации (специалоно для Nikolay M. ©):

А в [11] типы мне не иначе как звезды подсказали.

> Где посмотреть?

Если BOL-ом умеешь пользоваться, зачем спрашиваешь?
Но СПЕЦИАЛЬНО для тебя, например так: в ЕМ посмотреть для базы Generate SQL Script Preview.

← →
BPK (2004-05-17 10:45) [15]

Выяснилось, что после репликации возникает та же фигня.

← →
BPK (2004-05-18 10:22) [16]

Refresh

← →
BPK (2004-05-24 10:02) [17]

Короче говоря, я отказался от sql_variant. Перешёл на nvarchar. С ним гораздо меньше проблем.

Проблемы:
- sql_variant зависит от версии MDAC
- если в таблице имеется хотя бы одно поле sql_variant, то Enterprise Manager не даёт отредактировать ни одну ячейку ни одного поля
- При копировании с помощью DTS данные теряются

Я думаю, этого достаточно, чтобы признать тип sql_variant непригодным к употреблению.

> Проблемы:
> - sql_variant зависит от версии MDAC

Ы? Интересно.
Если не трудно, плз, как именно зависит и в чем траблы, чтобы не наступать потом на те же грабли.

странно, у меня пробы не дали отрицательных результатов, хотя для работы вариант не использую, всегда точно знаю типы полей :).
и кстати когда пробовал ([8]) использувал базу на недавно установленной машине без апдейтов (MDAC 2.5, максимум 2.6) а у меня 2,7. и тем не менее нормально.

нет тут чтото другое, и стопроцентно связаное с COLLATION (языками) возможно и в самой винде, может быть разные версии виндов? русская/английская и не настроенная?. может в качестве источника ODBC используется? он с юникодом не работает. а тут явно глюк на преобразовании юникода.

DTS портит данные типа sql_variant Найти похожие ветки