Иван FXS,

не бывает отображения числа без форматирования .
Увидеть то, что вы называете "полным" видом в строковом виде, отформатированном в виде числа для человеческого глаза нельзя.
Но вы можете завести двоичное поле на 8 байт с типом binary, записать туда свои числа, и уже после этого разглядывать разницу в их двоичных представлениях.

PS
Это странно - с упорством, достойным лучшего применения, из года в год заводить топики одной и той же степени удивления по части разницы между хранимым и отображаемым представлением числа, и прочих их особенностях.
Уже выберите время, и освойте тему фундаментально, раз она имеет для вас значение.

Без если и то - просто НЕ БЫВАЕТ , никогда, потому что не может быть




точно не путаю.

Debug.print не отображает двоичное представление числа, а отображает, см выше, форматированное для человеческого глаза
приблизительное значение, которое в каких-то обстоятельствах случайно может оказаться даже и точным.

Иван FXS,

ура.

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

Результат преобразования обеспечивается с набором оговорок, рассуждающих о том, что преобразование произойдет с "достаточной"
(для инженерного вычисления, например) степенью точности.

это они так называются в русском языке.

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

тогда вот здесь, наверно, был другой Иван, или тот, что есть сейчас, уже все забыл - и почему после двойного преобразования двоичное представление меняется, и почему непосредственно сравнивать такие числа - не самая умная идея:
Задачка

ЗЫ
Если вам "посередине" на самом деле нужна действительная арифметика удвоенной точности, не используйте хотя бы на этапе хранения вычисленных значений этот формат.
Уходите на восьмибайтные структуры двоичного хранения.
Применительно к Access это значит - храните полученные значения в полях binary(8).
Жизнь существенно упростится.

Умнее было было бы перестать писать совсем уж откровенный бред.

индекс с уникальными значениями формирует структуру, которая работает так, как должно работать то,
что в реляционной теории называется ключом. В этом контексте "ключ" и "индекс с уникальными значениями" - полные синонимы.

Правильная работа ключа целиком основана на наличии точных правил, позволяющих надежно сравнивать значения,
как минимум, на равенство/неравенство.
Менее важно, но используется для сортировки предположение о надежности сравнения на меньше.
Здесь вы добровольно объявляете ключом поле с заведомо ненадежными правилами сравнения.
Маловероятно, что это может вас устроить.

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

1) за логикой своих высказываний все-таки лучше следить.
Иначе может оказаться, что в истинные они обращаются только при ложности посылок.
Для того чтобы индексация работала, необходим сам факт наличия правил сравнения, а термин "надежные",
по крайней мере, в использованном вами смысле, требует уточнения.

2) кое-что, похоже вы забыли. Попробую напомнить:
2.а) Стандарт предполагает наличие двух нулей - положительного и отрицательного.
У них разные двоичные представления, но для vba несомненно, думаю, что и для Access как субд тоже, они всегда точно равны.
По крайней мере, полученный однажды в индексе отрицательный ноль не даст там появиться второму положительному.
Существенно это для вашего случая или нет - издалека неведомо.
2.б) VBA тщательно оберегает вас от получения NAN в качестве результата вычисления простого выражения сорта sqr(-1)
Однако из этого не следует, что он точно и несомненно не сможет у вас приключиться в вашем не показанном вычислении.
Я не знаю, что с этим делает Access - запишет он NaN в таблицу или откажет.
Но, если вдруг запишет, то ключ немедленно превратится в тыкву, поскольку NaN ничему не равен, в том числе самому себе.
Один раз попавший в уникальный индекс NaN обязан попадать туда произвольное количество раз.

Дальнейшее к ключу, само по себе не относится, но...
с) По отношению к "надежному" сравнению, что бы это ни значило, обычно "естественно" предполагают применимость правила транзитивности.
То есть, если a = b И b = c ТО несомненно a = c
На чем строится ваша уверенность, что транзитивность вообще применима к действительным числам двойной точности.
d) Следующее "естественное" предположение, что из a = b несомненно следует, что 1000*a = 1000*b
Вот это не обеспечивалось исторически ни первоначальными формулировками стандарта ни первоначальными фактическими реализациями.
e) умножение действительных чисел двойной точности, в общем случае, некоммутативно:
a*b и b*a не обязаны давать один и тот же двоичный результат.

Даже если сейчас во всей этой теме что-то исправлено, как методом уточнения стандарта, так и методом внесения исправлений в
железо, свободно манипулировать утверждениями безапеляционного типа в такой теме можно,
при условии что вы точно знаете и понимаете все особенности своего окружения.

Удачи в борьбе с отображением значений действительных чисел.

Не надо хранить результаты вычислений, выполненных в арифметике cdec в полях binary double.
Для этого у Access есть тип Numeric, точно соответствующий формату внутреннего представления таких чисел

И вы опять ошибаетесь, целиком "целочисленные внутри" - currency, у них и арифметика целочисленная..
Наличие шкалы в decimal существенно отличает арифметику в этом типе от обычной целочисленной.

Это критически зависит от года выпуска железа, по отношению к которому вы производите столь безумное суждение.
Они, исторически, могли оказываться равными при первом сравнении и не равными при втором.

ваши домыслы, сами по себе для меня давно не интересны.
Извините.

Верить вы можете вообще во что угодно.
Даже в такую фигню, как "вызов функции умножения всегда дает тот же результат" применительно к волшебным binary double


Вероятно, даже более того, персонально вам разрешено верить и в то, что два последовательных преобразования десятичного литерала 1000 в двоичное представление тоже всегда дает один и тот же результат.

В вашем тоже есть, только вы, может быть, не знаете, как его указать в визуальном интерфейсе.

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

А если в типе поля указать "числовой", а в размере сказать "действительное",
то ему можно задавать "точность" вплоть до 28, и тогда то, что получится, будет Numeric полем.

Проблема с ним только в том, что при любом способе его задания, вы не сможете хранить в нем результат произвольного decimal вычисления.
Только в рамках попадания в (точность, шкала).
Либо дробные хвосты обрежутся по шкале, либо значение не влезет в указанную точность.
Но если для вас достоверно значима только целая часть, то (28,0) позволит вам получить дополнительные разряды точного представления целого числа.