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@iki.fi wrote:
On Wed, 16 May 2012 18:06:08 -0300 Sebastian Ferguson sebastian.ferguson@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