SQL error 804

Доброго времени суток!
Сделал программку для работы с БД FireBird 2.0.1 Программа поочередно конектиться к разным БД и проверяет информацию. Подключение через IBDatabase
Путь к БД береться через диологовое окно.
У меня на компьюторе она работает нормально, принес я ее на работу и тут она начала чихать и кашлать.
На работе на моей машине НЕ установлен FireBird, программа отказывалась открываться вообще. Скопировов в папку с программой gds32.dll, начала открываться, но не хотела выполнять подключене к БД, постоянно вылетела ошибка "Unavailable database". Но к сожелению эту проблему я так и не решил, поставил FireBird 2.0.1 на рабочую машинку. После установки FireBird 2.0.1 программа стала подключаться к БД и выполнять возложенную на нее миссию, счастье мое длилось не долго. Так как после обработки 5 записи в БД она выдала следующую ошибку "SQL Error cod -804 Count of read-write columns does not equal count of values", проверил записи в БД, ничего подозрительного не обнаружил, прийдя домой первым делом полез в код программы, но как не странно там тоже все нормально. Запустил программу, все работает как надо и без ошибок.
В чем может быть дело?

И так, после мозгового штурма проблема решилась, ошибка "SQL Error cod -804 Count of read-write columns does not equal count of values" была ликвидирована путем смены РЕГИОНАЛЬНЫХ НАСТРОЕК (разделитель целой и дробной части) вместо "," надо было поставить "."

[телепатический локатор включен]
уж не собираем ли мы вручную SQL-запрос, содержащий вещественные числа/даты, вместо использования параметров?
[телепатический локатор выключен]

Добавлено 29.01.09, 07:24
ага, угадал - не региональные настройки надо менять, а параметры использовать!

Цитата Игорь Акопян @ 29.01.09, 07:23

параметры использовать!

Да? Надо попробовать.

Дело, конечно, прошлое, но как показывают наблюдения, многие и сейчас, особенно начинающие, натыкаются на грабли "РЕГИОНАЛЬНЫХ НАСТРОЕК" и, как следствие: "Count of read-write columns does not equal count of values".
Пишет, пишет программер. Понаписал несколько тыщ строк, а тут, бац и облом: "на одной машинке работает, на другой не работает, ПАМАГИТЕ!"
Параметры то, как советует Игорь Акопян, дело хорошее, но не всегда есть возможность или желание переделывать исходники.

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

...
initialization
  DecimalSeparator := '.';
  DateSeparator := '.'; //на всякий случай
end.

DecimalSeparator и пр. глобальные переменные. Через них можно заменять региональные значения на время работы программы.

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

Сообщение отредактировано: sansans - 15.03.11, 05:39

Цитата sansans @ 15.03.11, 05:21

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

      ...
      initialization
        DecimalSeparator := '.';
        DateSeparator := '.'; //на всякий случай
      end.

DecimalSeparator и пр. глобальные переменные. Через них можно заменять региональные значения на время работы программы.

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

Позвольте осведомиться, уважаемый joiner, в чем же крамола этого метода решения проблемы?
А то только эмоции, без аргументов.
В справке Delphi нет ни гу-гу про то что нельзя "вмешиваться в эти настройки". Кстати, никакая это не настройка; при запуске любой дельфийской программы значения этих переменных берутся из региональных настроек и никаким образом не заменяют их в винде.
Да и при многолетней практике такого вмешательства не было замечено никаких отклонений от нормальной роботы программ.
И, потом, я не призываю применять изменение значений глобальных переменных вместо нормального программирования. Это лишь способ избежать непомерных трудозатрат в некоторых ситуациях (если заметили, конечно).

Сообщение отредактировано: sansans - 15.03.11, 06:58

Цитата joiner @ 15.03.11, 05:54

нечего вмешиваться в эти настройки

Это локальные настройки программы.

Цитата sansans @ 15.03.11, 06:53

Позвольте осведомиться, уважаемый joiner, в чем же крамола этого метода решения проблемы?

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

Здесь я с вами резко соглашусь.
Но ведь и речь то шла именно о том, чтобы выбранные пользователем региональные настройки никоим образом не менялись. И вышеописанный прием как раз это и позволяет делать разработчику, который пишет приложения на Delphi с использованием SQL СУБД.
Скорее всего, вы не поняли, что изменения значений глобальных переменных в Delphi никак не затрагивает региональные настройки в винде и наш пользователь как имел их в первоначальном виде, так и имеет.
Для всех своих программ. А при конвертировании числа в строку "срабатывают" измененные гл. переменные.
Т.е. плохого мы ничего не делаем и "больно бить по рукам" за то что в Delphi много чего предусмотрено, а программеры это использует, думаю, не стоит.

sansans, направление достаточно верное, но не совсем. Описанные тобой переменные повлияют на ВСЮ программу в целом. То есть, из-за внутренностей SQL, к примеру, бухгалтеры столкнутся с невозможностью копипейста прога <-> эксель/1с/калькулятор. Это не айс совершенно. А решение - в замечательных перегруженных функциях Format, FormatDateTime, ... с параметром типа TFormatSettings. Туда можно подсунуть любое нужное значение региональных настроек без влияния на остальные части программы.

Добавлено 15.03.11, 09:01
К сожалению, с обратными функциями StrTo*** такого блага не предусмотрено

Согласен, "копипейста" прямого не получится (и то, правда, не всегда; к тому же не везде и требуется). Но это не самое страшное зло - на самом деле мало кто пользуется прямым (ручным) "копипейстом". А в программе этот пресловутый "копипейст" можно исправить как нужно.
Но, надо заметить, я привел прием, которые позволяет УЖЕ ГОТОВОЕ приложение исправить малой кровью.
И, наконец, полностью присоединяюсь к авторам постов, которые проповедуют делать все как надо с самого начала.

Цитата Fr0sT @ 15.03.11, 08:59

бухгалтеры столкнутся с невозможностью копипейста прога <-> эксель

Если поле текстовое то столкнутся, если числовое то нет.

sansans, ты привел прием, а я написал, как этот прием максимально изолировать во избежание самых разнообразных глюков.
Простой пример и без всякого копипаста.
1) Ставим DecimalSeparator = '.'
2) В Edit1 вводится некое float число. Разумеется, с региональным разделителем
3) f := FloatToStr(Edit1.Text) => БАМС! Эксепшен

Сообщение отредактировано: Fr0sT - 15.03.11, 13:35

А этот "БАМС! Эксепшн" разве не будет, если в региональных настройках установлена точка, DecimalSeparator не применяем, а вводим число с запятой? Все будет точно так же.

Приходится повторять, что проблема с региональными настройками будет всегда и разработчик, хочет он или не хочет, обязан её учитывать. Вот и все. А как он это будет делать с DecimalSeparator, через TFormatSettings, установкой у клиента виндовых настроек или, наконец, проверкой чего пользователь вводит в Edit - это его личное дело.