Выборка из SQLITE

[Tamachi]

Работаю с SQLite следующим образом:

String where ="("+MY_COLUMN_NAME+"=?)";
Cursor cursor = m_readableDB.query(MY_TABLE_NAME, null, where, new String[] { String.valueOf(MyValue) }, null, null, null);


Столбец MY_COLUMN_NAME в БД определён как INTEGER;

По идее, это код должен выбирать и базы все записи у кторых MY_COLUMN_NAME=MyValue

Такие записи в БД есть, но cursor возвращается пустым.

Я что-то не так делаю?

Уже третьи сутки ломаю голову над тем, как сделать банальный SELECT из базы!

[Foenix]

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

[neoksi]

MyValue у тебя имеет тип int?

Если да, тогда Integer.toString(MyValue).

[Tamachi]

MyValue у тебя имеет тип int?
long
Если да, тогда Integer.toString(MyValue).

Причина оказалась была в том, что SQLite неправильно хранит данные типа real.

(Один из соседних столбцов имеет тип real)

Поскольку в SQLite нет типов столбцов, все данные хранятся в строковом виде.
При этом представление десятичной точки зависит от текущей локали.

Получается что данные типа real надёжно хранить в SQLite невозможно.
На некоторых аппаратах это работает, а на оставшихся (то есть на тех, где SQLite нелокализован -- а таких большинство!!!) -- работает с ошибкой. При этом в эмуляторе всё работает!

Пока в шоке. Думаю, что делать.
Кто-нибудь уже сталкивался с подобной проблемой?

Кстати, почему, во многих учебниках рекоммендуют использовать тип столбца FLOAT, в то время как в официальной докумментации к SQLite этот тип называется REAL. Кому верить?

[Mikhail_dev]

Причина оказалась была в том, что SQLite неправильно хранит данные типа real.

А можно ссылочку? А то я что-то не пойму.

При этом представление десятичной точки зависит от текущей локали.

Если нужна точность данных, то и float, и double здесь идут лесом. Это известная истина. Юзайте BigDecimal.

Кстати, почему, во многих учебниках рекоммендуют использовать тип столбца FLOAT, в то время как в официальной докумментации к SQLite этот тип называется REAL. Кому верить?

Там еще написано ( http://www.sqlite.org/datatype3.html )

If the declared type for a column contains any of the strings "REAL", "FLOA", or "DOUB" then the column has REAL affinity.

Т.е. другими словами, на сколько я понял, float и double будут приведены к типу real. Почему при этом float рекомендуют, понятия не имею.

[Tamachi]

Вот чего я не понимаю, так это какого фига Гугл из всех известных опенсорсных БД выбрал самую мерзкую дрянь -- SQLite.
Отсутствие типизации данных, отсутствие многопоточной записи, неэкономичный формат данных, зависимость от локали...
Чтобы заставить все это работать Гуглу пришлось написать уйму всяких костылей типа ContentProvider, DBHelper и пр...
Что, нельзя было взять хотя бы mongodb, mysql, ну на худой конец свою написать -- и то лучше чем пожизненно на костылях ходить!

[Foenix]

что значит гугл выбрал? выбирай что хочешь - любую БД.
у sqlite много преимуществ, ее мир выбрал

[rezak90]

да куча разных дб под андроид есть, какую использовать выбирать тебе, тем более sqlite не самая быстрая

[Tamachi]

что значит гугл выбрал? выбирай что хочешь - любую БД.
у sqlite много преимуществ, ее мир выбрал

Я имел в виду, что SQLite -- это встроенная в андроид БД.
Внедрять свою -- это увеличивать объем кода и время разработки. => неприемлемо.

[Tamachi]

что значит гугл выбрал? выбирай что хочешь - любую БД.
у sqlite много преимуществ, ее мир выбрал

Не знаю, какой там мир её выбрал. Я не выбирал.

Кстати, назовите мне хотя бы одно преимущество SQLite.

[Foenix]

Да не встроенная она!

[Tamachi]

Да не встроенная она!

С этого места поподробнее!!!

Почему не встроенная?

[Mikhail_dev]

Мне тоже стало интересно, почему она не встроенная.
А из преимуществ? Да она вполне себе шустрая!

[Tamachi]

Мне тоже стало интересно, почему она не встроенная.
А из преимуществ? Да она вполне себе шустрая!

Ни фига она не шустрая!
Шустрой она становится если отключить автоинкремент индекса, что на мой взгляд в большинстве приложений неприемлемо!

[Tamachi]

Долго мучился и решил проблему следующим образом:
В БД SQLite будет храниться не double, а integer.
При записи double умножается на KOEFF и приводится к целому числу.
При чтении число читается из БД SQLite, делится на KOEFF и приводится к типу double.

Согласен, что решение кривое, медленное и ресурсоемкое. Но никак по-другому SQLite не умеет!

Мало того, что она совсем не шустрая. Она просто провоцирует программиста, чтобы он навешал
на неё костылей и сделал её ещё более медленной!!!

Если кто-нибудь предложит другое решение -- буду весьма благодарен.

[Mikhail_dev]

Я не пойму, где написано что она вещественные числа неправильно хранит?

[Tamachi]

Дык в том-то и дело, что нигде не написано. Написано, что всё зашибись, а на самом деле -- фигня.
Если бы всё было по-написанному, то и проблем бы не было.

[rezak90]

не пойму что за гон на SQLite, сколько её используем то не было проблем ни с вещественными числами ни со скоростью

[Foenix]

не пойму что за гон на SQLite, сколько её используем то не было проблем ни с вещественными числами ни со скоростью

я тоже довольна

Мне тоже стало интересно, почему она не встроенная.
А из преимуществ? Да она вполне себе шустрая!

Ни фига она не шустрая!
Шустрой она становится если отключить автоинкремент индекса, что на мой взгляд в большинстве приложений неприемлемо!

сколько у вас записей?

Насчет встроенности. Она не встроенная, она встраиваемая, это рзаные вещи, т.е. встроенной она становится только после того, как вы ее сами туда приколбасили.
Никто не запрещает выбрать любую другую - я например использую и ее и sql server, ни в чем ни в том не чувствую себя ущербной.
Да, деньги (до копеек) лучше держать в целых числах, потом два знака отрубать (хотя сейчас копеек нет, все округляется). Но проблемы с деньгами в базах - это не только в ней могут быть, но и в других БД.

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

[Mikhail_dev]

Она не встроенная, она встраиваемая

Встроенная - это когда что-то железно входит

В состав Андроида, java или чего-то там еще она не входит.

Она входит в состав андроида по дефолту. Мне не надо никакие библиотеки подключать дополнительно, ибо андроид имеет эту СУБД по дефолту. А значит встроенная по дефолту. И не страдайте маразмом в плане доказательств как правильно это называется, встраиваемая или встроенная.

Дык в том-то и дело, что нигде не написано. Написано, что всё зашибись, а на самом деле -- фигня.

Третий раз спрашиваю. Можно конкретики? Можно какой-то пример что ли?
Почему я прошу это сделать, потому что я практически уверен, что проблема тут не в СУБД, а в использовании в коде типов double или float, которые тоже не виноваты, ибо всему виной представление вещественного числа в самом компьютере. Есть нюансы. Про это можно легко нагуглить. Я написал какой тип позволяет избежать проблем.
И на счет производительности я бы тоже хотел глянуть, где она медленная. Я читал только одно мнение везде, что она быстрая. На том же самом stackoverflow. Что бы тебе теперь поверить, мне надо бы хотя бы увидеть хоть какие-то тесты.