Всем доброго и времени суток тоже.
Задача, в общем, такая: есть DBL_MAX = 1.7976931348623158e+308.
При добавлении значения в поле f1 таблицы t1, заявленное, как SQLITE_FLOAT запроса
insert into t1(f1) values(1.7976931348623158e+308) база не понимает и на чтение выдает 1.#INF. Вменяемые значения возвращаются при записи числа несколько меньшего, примерно 1.7976931348623140e+308. При работе через sqlite3_bind_double проблема исчезает, что записано, то и возвращается, тютелька в тютельку. Но, возникает следующая задача - сделать таблицу со значением поля по умолчанию аккурат в DBL_MAX. запрос insert into t1 values(?) работает вполне. а вот на запрос create table t1(f1 SQLITE_FLOAT default ?) базочка возражает, что вопросительных знаков не хотет. Вопрос - как такое можно сделать? за идеи спасибо!

отвечаю, по порядку:
SQLITE_FLOAT - один из пяти внутренних типов данных SQLite. http://www.sqlite.org/datatype3.html
на основе приведения типов (по ссылке), если в таблице присутствует "FLOA", значение хранится, как, цитирую, REAL. The value is a floating point value, stored as an 8-byte IEEE floating point number. от так.
DBL_MAX - константа из файла float.h стандартной библиотеки c, есть даже в украинской педивикии, ограничение в работе с плавающей точкой. тоже где-то так, константа взята не с потолка.
касательно актуальности задачи - вопрос, согласен. изначально была объектная БД, и в поле координат (например) значение считалось не заданным, если стояло DBL_MAX. соответственно, есть килотонны кода, где ентот DBL_MAX уже используется, ноги, тащемта, выросли оттуда. Согласен, реляционные БД имеют такую штуку, как NULL (SQLITE_NULL в данном случае), но тем не менее, мне уже тупо интересно.
собственно, два вопроса: почему при конвертации из строки возникает ошибка (число неправильно, походу, конвертируется внутре SQLite) и, вдогонку, почему при создании таблиц нельзя пользоваться байндом?

MGB, ссылку на SQLite/типы данных я привел постом выше, перепост - весч, читайте все посты, их было три, это не так уж сложно.
касательно сравнения значений типа DOUBLE - ясен пень, есть точность вычислений и все такое. При этом код вида
#include <float.h>
...
double d = DBL_MAX; //1.7976931348623158e+308
if(d==DBL_MAX)
{
естественно выполнится вот тут, хотя в d будет значение, отличное в последней цифре (хвост 7999...)
}

проблема в том, что
1) результат выполнения кода
1.1)
sprintf(str,"insert into table values(%e)",d); sqlite3_prepare_v2(...,str,...);...
и кода 1.2)
sqlite3_prepare_v2(...,"insert into table values(?)"); sqlite3_bind_double(..,d); ...
существенно различается. в первом случае на чтение имеем 1.#INF, во втором - в точности DBL_MAX.
и 2) при создании таблицы невозможно (или у меня руки кривые) пользоваться sqlite3_bind... .

сломаный детектор детектед.
во-первых, где вы увидели приведение к типу int? протрите глазки, тип - %e, а вот d - это число типа double.
Да, невозможно, согласно документации SQLite ссылочку или цитаточку можно?

MBG , мб, я совсем косой, но там нет ни слова о том, что в запросе create table ... невозможно использовать байнды. Insert, Replace, Delete, Select - все можно, в where-стэйтментах, итд - можно, а в create table нельзя. если не сложно - ткните пальцем

White Owl , If the declared type for a column contains any of the strings "REAL", "FLOA", or "DOUB" then the column has REAL affinity., и, как я уже приводил, REAL. The value is a floating point value, stored as an 8-byte IEEE floating point number чудесно, не правда ли?

RXL , премного благодарен за тест, я на консольную управлялку забил сразу и никогда не пользовал. забавно.
с sprintf проблем нет, в строке досимвольно 1.7976931348623158e+308. более того, с числом 1.7976931348623150e+308 (последний нуль) проблем также не наблюдается, что, собственно, меня и озадачило. попробую поиграть с версией компилятора, хренота была под шестой студией (mcvs 6.0).

вести с полей.
RXL , командный shell у меня ведет себя совершенно также ( в смысле, с ошибкой, а не как у вас) - значение DBL_MAX преобразуется на чтении в inf. более того, при определенном запросе shell с легкостью вылетает (корень зла в библиотеке, под студей тоже самое), ниже опишу)

White Owl , по пунктам:
1) а судя по остальным постам этого топика у тебя явная проблема со sprintf,
я, есть вероятность, не совсем дибил, в строке досимвольно DBL_MAX, о каких проблемах с sprintf может идти речь? вероятнее, проблема в sqlite, при внутренних преобразованиях к типу
2) Мало-ли какой там тип данных заявлен, главное что ты посылаешь заявлено - SQLITE_FLOAT, через байнд запись проходит совершенно успешно, отправляю double, получаю тоже double. наверное, если бы был заявлен текст в той или иной форме, то проблемы бы не возникло, правда? все равно, что хранить "100e+1000" или "бармалей-чемпион". 1.#inf в случае не флоата получить было бы проблематично.
3) Операция привязки может работать только где есть к чему привязываться. Если ты найдешь параметры у create table - ты сможешь использовать sqlite3_bind() на этом запросе.
sqlite 3.7.2 или 3.7.8
http://sqlite.org/syntaxdiagrams.html#column-constraint
картинка, на ней стрелочка->DEFAULT->signed number либо literal value либо expr в скобочках. Вон, товарищ мне тут про экспрешшон кидал. это не место, куда надо привязываться?


вот тут, собственно, словил ошибку в лайте:
запросы:
create table t1(one int default 100);
insert into t1 default values; - приводят к появлению в базе значения 100, а запросы:
create table t2(one int default (?));
insert into t2 default values; - приводят к падению базы вместе с приложением, её использующем
попробуйте, а? мб, у меня только так всё плохо

не дебил, да, самофикс

Шум? кто бы говорил.
literals это значения и identifiers - имена таблиц, полей,.. Как видим, имена таблиц/функций и проч. не могут биндиться как параметры.
значение по умолчанию - не имя таблицы или функции. я уже привел место в create-запросе, column-constraint, где вполне себе указано expression.

полнейшее непонимание десятичной арифметики, да, меня мама учила до трех считать.
sqlite вполне возвращает точное значение в случае использования bind. Через строку - нет, притом, что отправляемая строка точна, как курс на нептун. sscanf из строки тоже легко вытаскивает DBL_MAX, так что тут проблема должна быть в лайте