none
взаимодействие Access и Excel - чисто практический вопрос... RRS feed

  • Общие обсуждения

  •  

    всем доброго времени суток!

    Обозначения:
    Access = (А) Excel = (Е)


    Исходное:
    Есть 2 БД - одна в Е (в виде таблицы с массивом данных), другая в А (с тем же массивом, но по-другому представлена). Таблицу в Е делает одна фирма, а  таблицу в А - другая. Мне же выпала честь конвертации Smile Для пересчета данных в Е и подготовки к их передаче в А мне необходимо использовать формулу ОКРУГЛ (число1*число2*число3*...;3)  - вот мой синатксис. И на выхое получается некое Число (необходимое одной фирме). Далее я использую программу, написанную на основе А и испльзующую встроенные возможности А. При конвертации данных А эти самые данные пересчитывает по формуле ROUND и сравниваются с исходынми данными в Е и возникают расхожения.

    Вопрос:
    Как этого можно избежать? Если в Е используется ОКРУГЛ, а в А используется та же ROUND? У меня создается впечатление, что обе эти программы по-разному трактуют одни и те же законы математики.

    наглядный пример - см. на рисунке.

    Заранее спасибо всем тем, кто отзовется.

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

     

    http://img125.imageshack.us/img125/5518/untitled1zx7.jpg

     

    Версия А и Е - 2002 (10.2701.2625)

    4 сентября 2007 г. 16:00

Все ответы

  • Посмотрел картинку.

     

    Навскидку приходит одна мысль. Все дело в том, что Е работает со всеми разрядами числа, а отображает только те, которые указаны в формате ячейки. При этом, Е отображаемый результат тоже округляет.

     

    Другими словами, в ячейке G5 может храниться число 6,4125, которое при отображени (!!!) округляется до 6,413, а данные в ячейке H5 из А м.б. были отбрезаны (по незначащим разрядам) в самом А (например, форматом поля таблицы - число десятичных знаков), поэтому и получается 6,412.

     

    Прорверь. Это вполне может оказаться решением, т.к. явлеется довольно частой ситуацией.

     

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

    5 сентября 2007 г. 7:52
  • Все дело в том, что Е работает со всеми разрядами числа, а отображает только те, которые указаны в формате ячейки.

    Сдается мне, что и Е и А работают таким образом, но я свожу их к одному знаменателю - формуле ОКРУГЛ - и как бы они не работали - они ДОЛЖНЫ подчиниться одному правилу. В Е можно сделать - отображать 2,3.. .знака после запятой и при этом, как вы верно подметили, Е будет считать все циферки но округлять визуально до нужного знака. Но ОКРУГЛ подразумевает отсекание знаков.Я извиняюсь, может не внес сразу ясность, но значения в ячейках G5-10 считается через ОКРУГЛ до 3го знака.

     

    при обработки данных пришедших из разных источников...

    а Е и А, сдается мне, это одно целое и должны понимать друг друга на ура (ведь входят они в один единый пакет Офиса)

     

     

    Т.е., проще говоря, используя  ОКРУГЛ в Е и ROUND в А не эквиваленты? Кстати, на ROUND как-то без примеров нашел описание

    http://office.microsoft.com/ru-ru/access/HA012289021049.aspx?pid=CH100728911049

    и не более того.

    5 сентября 2007 г. 8:46
  • Я может быть не правильно выразился, поэтому поясню.

     

    ОКРУГЛ и Round работают одинаково, и как Вы действительно заметили, Е и А работают как единое целое. Сам часто использую такую связку. Однако...

     

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

     

    Советую сделать такое пример.

    1. Создайте в Е таблицу с числами (например, функцией СЛЧИС). Создайте в А пустую таблицу, указав в спойстве поля (естественно числового) три разряда после запятой. Перенесите данные из Е в А (например, запросом или импортом данных). Посмотрите результат. 
    2. Создайте в А таблицу, в которой задайте максимально возможное количесво знаков после запятой. Запишите числа из Е. Проведите ОКРУГЛ в Е и Round в А. Посмотрите результат.
    3. Сравните полученные результаты.

    Успехов

    6 сентября 2007 г. 8:27
  •  

    Максим,

    спасибо за разъяснение. Я проделал манипуляции по указанным примерам и лишний раз убедился, что Е действительно "держит в уме" лишние знаки, а А - четко их отсекает. И по этому вопрос - а каким образом прийти к общему знаменателю? Через какую ф-ю, аналогичную ОКРУГЛ? Говоря откровенно, я сильно глубоко Е не знаю - никогда не было такой необходимости, а из предложенных ф-ий ничего подходящего не вижу.
    И еще такой момент - обратите внимание на последнюю строку моего примера (6,782-6,783) - там, где без округления получается 3 знака  после запятой, но А почему-то все равно уменьшает на 1 тысячную. Я не вижу этому объяснений.

    8 сентября 2007 г. 12:56
  • Посмотрел. И опять же могу лишь сказать, что это связано с механизмом хранения данных в Е и А. Другими словани, т.к. А для каждого числа в вычислениях "отрезал хвостики" (м.б. даже очень маленькие, например при суммировании), а Е - не отрезал, все же в результате высилений получились чилса без незначаших разрядов, поэтому и с округлением, и без у Вас, опять таки , получились разные данные.

     

    Что можно сделать в данном случае:

    1. В Е перед вычисления все данные "обрезать" или округлять до значащих разрядов. Лучше думаю "обрезать", т.к. А именно это и делает. Это может минимизировать, но не устранить полностью, количество фактов проявления таких ситуаций.
    2. В А модифицировать таблицу с данными, увеличив количество значащих разрядов. Результат тот же - минизация фактв проявления. Однако, если данные к Вам приходят извне и Вы не можете повлиять на их структуру, то этот способ може и не сработать. Он также может не сработать, если пользователям А будет "влом" набирать лишние разряды.
    3. Использовать метод 1 и 2 одновременно. Другими словми изначально приводить данные к некому единому виду с протоколированием возможныхх расхождений и критериев адекватности результата. К сожаление такое допущение нельзя использовать для балансных данных, наприер, бухгалтерских или "строгой отчетности".

     

    Успехов

    10 сентября 2007 г. 15:49
  •  

    Максим,

    1. А как можно обрезать в Е лишние разряды после запятой? Через какую ф-ию? Пусть хотя бы расхождений будет меньше.
    2. К сожалению, кол-во разрядов нельзя менять - оно должно быть четко 3 знака после запятой.

     

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

     

    Да просто перемножьте эти циферки на калькуляторе, отстранившись от Е и А. Там округлять просто нечего. Там всего - 3 знака получатется после запятой. Smile  Но А все равно (как?) уменьшает на тысячную.

    14 сентября 2007 г. 7:28
  • Думаю может помочь это...

     

    ОТБР(число;число_разрядов)

    Число  — усекаемое число.

    Число_разрядов  — число, определяющее точность усечения. Значение по умолчанию — 0 (ноль).

    Замечания

    Сходство между функциями ОТБР и ЦЕЛОЕ заключается в том, что обе они возвращают целые числа. Функция ОТБР отбрасывает дробную часть числа. Функция ЦЕЛОЕ округляет число до ближайшего целого с недостатком с учетом значения дробной части. Эти функции различаются только при использовании отрицательных чисел: TRUNC(-4.3) возвращает значение -4, в то время как INT(-4.3) возвращает -5, поскольку -5 — ближайшее меньшее число.

    2 октября 2007 г. 7:48
  •  

    Максим,

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

    30 января 2008 г. 15:13