Error 3759

Коллеги, на простой запрос по связыванию двух других запросов пишет такую инфо:

"Изменение маштаба десятичного занчения приводит к усечению данных"

По справке:
Scaling of decimal value resulted in data truncation. (Error 3759)
This error occurs when the data being updated or inserted into a DECIMAL data type does not match the defined scale and precision of the column.

И запрос не общий запрос не отрабатыется, хотя отдельно каждый отображается нормально.

Объясните пож. доступным языком, что за проблема?

С ув. AndreyODBC

AndreyODBC,

Какая версия Access и формат файла?

Наверное у Вас линкованные таблицы, которые реально возможно находятся на стороне SQL Server. И быть может Вы использовали тип данных что-то вроде Numeric(p, s) или Decimal(p, s) (где вместо p, s - количество разрядов).
Если всё именно так, то попробуйте заменить тип данных на Float и запустите Ваш запрос.

Угадал?

studieren
AndreyODBC, ...попробуйте заменить тип данных на Float и запустите Ваш запрос....

Иными словами, Вы предлагаете провести усечение значений и потерю точности представления прямо в базе.
т.е. - испортить данные.
Интересный заход. Особенно, с учетом того, что, может быть, не его данные.

booby,

Уважаемый, где Вы увидели, чтобы я просил изменить таблицу? :)
Чтобы заменить тип данных вовсе не обязательно менять структуру данных, достаточно запрос к серверу или же состряпать view, где следует "подправить" тип данных.
Что-то в этом роде:

SELECT CAST(Field1 AS Float) FROM dbo.Table1

Ну и надо посмотреть какие данные всё-таки хранятся в БД. Возможно сверхточность и не требуется. Например, для копейки и float годится, только в сверхточных расчётах надо быть осторожным. Даже в таких случаях ROUND и другие "корректировщики" точности могут быть достаточным.

автор
Например, для копейки и float годится,

есть мнение, что Вы заблуждаетесь.

По крайней мере, так не думают изобретатели типа Currency.
Они считают, что деньги в типе float ни хранить, ни складывать нельзя.
Это не вопрос "сверхточных" расчетов.
Это просто здравое ожидание того, что когда вы к одной копейке добавляете еще одну, то либо в ответе у вас должно оказаться две копейки либо вы должны получить ошибку - "не можу выполнять сложения".
Тип флоат вместо этого сделает лучшее, из того, что может.
А может он, кроме ошибки, оставить одну копеку в ответе или, наоборот, получить 3,4,... - как фишка (бОльшее слагаемое) ляжет.

Записи выбираю действительно из SQL сервера с вьюшек. Но выбираю в Access в формате как есть. Ошибка несколько идентифицировалсь в первоначальном запросе на вьшку, нашел конкретную запись в которой по всем полям записи (и текст и числа) #Ошибка, #Ошибка ... и 4 раза вышеиописанное сообщение выскакивает. К чему RUOND применять, если все поля в записи сбоят и даже текстовые?

С ув. Статиенко Андрей

AndreyODBC
Записи выбираю действительно из SQL сервера с вьюшек. Но выбираю в Access в формате как есть.

Вы наверное меня не поняли. Я спросил формат файла, в смысле ".mdb", ".adp", ".accdb" или что там у Вас ещё.

AndreyODBC
К чему RUOND применять, если все поля в записи сбоят и даже текстовые?

А зачем Вам Round? Он Вам не поможет. :)
Вы уж лучше тип данных базовой таблицы бы показали, ну и SQL текст Вашего представления (view).

booby

есть мнение, что Вы заблуждаетесь. По крайней мере, так не думают изобретатели типа Currency. Они считают, что деньги в типе float ни хранить, ни складывать нельзя. Это не вопрос "сверхточных" расчетов. Это просто здравое ожидание того, что когда вы к одной копейке добавляете еще одну, то либо в ответе у вас должно оказаться две копейки либо вы должны получить ошибку - "не можу выполнять сложения". Тип флоат вместо этого сделает лучшее, из того, что может. А может он, кроме ошибки, оставить одну копеку в ответе или, наоборот, получить 3,4,... - как фишка (бОльшее слагаемое) ляжет.

И что Вы предлагаете? Access (по крайнем мере А2003) не очень "дружит" с такими типами данных как "Date", "Numeric(p, s)", "Decimal(p, s)", "Smallmoney", "Money" и другие типы.
Допустим, у Вас в наличии А2003 и SQL Server 2008, а Вам нужно хранить скажем копейки. Тогда как Вы поступите? На стороне сервера нету типа "Currency", но есть "Smallmoney" и "Money".
Если есть альтернатива, ну тогда напишите. Только вот "Smallmoney" и "Money" выбирать нельзя, иначе будут выскакивать точно такие же ошибки как ТС написал. Я с удовольствие прочту и учту на будущее.

AndreyODBC,

Ну в принципе есть ещё 1 выход. В таблицах действительно можно не менять типы данных, а оставить как есть. Но только в представлениях нужно будет преобразовать с помощью CAST или CONVERT в нужный Access'ом "понимающий" тип. Но тогда эти поля как бы станут необновляемыми. Но и здесь есть выход. Нужно будет сочинить триггер INSTEAD OF, который и будет вносить соответствующие изменения в базовых таблицах. И тогда эти поля станут как бы обновляемыми (юзеры точно не заметят разницу).

И что Вы предлагаете? Access (по крайнем мере А2003) не очень "дружит" с такими типами данных как "Date", "Numeric(p, s)", "Decimal(p, s)", "Smallmoney", "Money" и другие типы. Допустим, у Вас в наличии А2003 и SQL Server 2008, а Вам нужно хранить скажем копейки. Тогда как Вы поступите? На стороне сервера нету типа "Currency", но есть "Smallmoney" и "Money". Если есть альтернатива, ну тогда напишите. Только вот "Smallmoney" и "Money" выбирать нельзя, иначе будут выскакивать точно такие же ошибки как ТС написал. Я с удовольствие прочту и учту на будущее.

Кхм…кони … люди …

Давайте как-нибудь отделять

Причин, по которой у топикстартера возникает именно его ошибка, может быть несколько
Одна из возможных указана в файле

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=492885&msg=4900746

на странице 13 – decimal столбец выбран в качестве ключевого и Jet не может правильно позиционироваться из-за потери точности. Решение – выбрать другой локальный уникальный индекс.

Другая в этом же документе на странице 14 (How ODBC Datatypes Are Mapped to Jet Types) – если precision > 15 и csale <> 4,
То происходит примерно следующее: пока числа не слишком большие, Jet транслирует их в double, затем встречая значение, не укладывающееся в правила, показанные в таблице ,
Он перескакивает к правилу преобразования, показанному в примечании к таблице.
С точки зрения Jet – это смена типа значения в столбце. Что и приводит к характерной ошибке.
Хорошего решения я не знаю. Сам, вероятно, предпочитал бы явную конвертацию к строке с обратным преобразованием к decimal на клиенте.
Ошибка такого сорта не проявится, если значения в столбце окажутся одного порядка.
Столбец либо нормально отобразится как допустимое по таблице конвертации числовое значение, либо как текстовое.

Касательно остальных коней и money в частности.
Money и smallmoney не имеют размерных проблем и при всех нормальных случаях должны безошибочно преобразовываться к currency.
Если с ними какая-то проблема, то, почти наверно, она лежит в плоскости несовпадения локальных установок для сеанса, обслуживающего соединение и локальных установок, используемых jet.
Для линкованных таблиц это должно решаться настройками драйвера, отвечающими за локализацию сеанса. (Может быть, еще – подбором драйвера. Какой-то из них м.б. предпочтительней другого для конкретной версии сервера)
Для ADP, вероятно, придется испустить подходящий DOCMD.RunSQL (см форум – RunSql в контексте ADP)

PS
я не работаю ни с акцессом, ни, тем более с скл сервером.
Поэтому никаких конкретных рекомендаций, проверок, демонстраций и т.п. не привожу.