[SR-Users] SQLite datatypes

[Sebastian Ferguson]

Hi Timo:

I've tryied with varchar(20) (lowercase) before I sent the original e-mail
and it doesn't work. And I have tryied storing data as a number and as a
stirng (I know that sqlite has not stict type definitios).

After your e-mail I've built the database again like this (all uppercase as
you recommend (and as it should be ;-)):

sqlite> CREATE TABLE traducciones('zona' VARCHAR(25), 'e100' VARCHAR(20),
'e101' VARCHAR(20), 'e102' VARCHAR(20));
sqlite> INSERT INTO traducciones
VALUES("caballito","1557311721","1557311721","08103330303");
sqlite> INSERT INTO traducciones
VALUES("flores","63793266","08103330303","1557311721");
sqlite> select * from traducciones;
caballito|1557311721|1557311721|08103330303
flores|63793266|08103330303|1557311721

AND NOW IT's WORKING!!!!!

The production table will have all emergency numbers in Argentina (10x,
13x, 911).

Best regards and thank you very much!!!
Sebastián Ferguson


On Thu, May 17, 2012 at 1:45 PM, Timo Teras <timo.teras at iki.fi> wrote:

> On Wed, 16 May 2012 18:06:08 -0300 Sebastian Ferguson
> <sebastian.ferguson at gmail.com> wrote:
>
> > I think this is related to data types.
> > In the logs I can see that kamailio is defaulting datatypes to INT
> > (I've tested varchar, int, and bigint in sqlite3), but I don't know
> > how large could an integer be in Kamailio. According to sqlite3
> > documentation the number 8003330303 is not long enough and in fact
> > the number is in the database.
>
> Yes. Sounds definitely like it's treated as INT instead of string or
> BIGINT. Since it's address part, it should be string (as there can be
> letters too).
>
> SQLite is a little bit unusual on how the typing system works. It does
> not really care about how you define your tables, it just stores the
> data there as given. That is, even if your table is specified as INT,
> it can still have STRING in it.
>
> I wrote the SQLite driver to consult the table declaration to see what
> there should be. So the driver tries to do the right thing, but
> apparently can go wrong in certain circumstances.
>
> However, I think either your table declaration is wrong. If the column
> is VARCHAR or TEXT it should work. Also, some of the tests are
> case-sensitive (strstr function used). Could you try if using uppercase
> VARCHAR or TEXT fixes it? If it does, I need to fix
> decltype_to_dbtype() to be case-insensitive.
>
> If possible, can I see the related table schema?
>
> - Timo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120517/6ae5968e/attachment.htm>