17 May
2012
17 May
'12
2:02 p.m.
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(a)iki.fi> wrote:
On Wed, 16 May 2012 18:06:08 -0300 Sebastian Ferguson
<sebastian.ferguson(a)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