Sqlite3 question

Problem:

#1

In sqlite3, how to insert REAL value using "thousands separator":

insert into mytable (ID, real_number) values (1, 9,999.9);

Returns "Error: 3 values for 2 columns"

But,

insert into mytable (id, real_number) values (1, 9999.9);

"works".


#2 - In sqlite3, how to select REAL value using "thousands separator":

However, in this case,

select * from mytable where id = 1;

returns "1|9999.9" (not "1|9,999.9")

So, how do I get sqlite3 to recognize, and use, the thosusands separator "correctly"?

Attached: fuck_sql.jpg (225x225, 7K)

Retard

Idk. RTFM?

Attached: simple-jack.jpg (199x253, 17K)

Okay . . . so what is the answer?

>picture for ants
>question for brainlets
Based retard making the post quality on this board worse than it already is

Attached: bonk.jpg (540x540, 44K)

>So, how do I get sqlite3 to recognize, and use, the thosusands separator "correctly"?
You do not.

You cannot use "," For anything except a parameter, except in a string. Hence you cannot use your strange separator. Just insert your value with numbers, or you could make a verification in whatever language you're used to by converting certain strings into real value before sending them in the database (by verifying each caracter in the string)

Thousands separator is formatting. Formatting does not belong in your database.

Try
insert into mytable (ID, real_number) values (1, '9,999.9');
and see what happens.

Also this

> "thousands separator"
Wat

Yes! That does work.

Thank you!

But I do wonder, is the value now being stored in the database as a REAL value, or as a TEXT value?

(The database was created with the real_number field as type REAL.)

Again, thanks for your reply.

Why don't you try and see what happens?

I did try it, and it does seen to work.

And since it does seem to respond to comparison operators as expected, I presume it still stores as a REAL value, and that the use of single quotes merely affects the display of the value to the user, not its "type".

Serious question:
Why doesn't formatting belong "in" a database.

Consider this: which is less likely to be erroneously typed in or read by the user?

364253986071
or
364,253,986,071

???

A database stores data. It doesn't give a fuck about readability or shit input from idiot users

Ask on stackoverflow

>Why doesn't formatting belong "in" a database.
Because it is the end user who should decide how to display the data for them. Next you'll tell us that you want to store dates in your local timezone, won't you?

because you use the database to store DATA. You then use some kind of user interface that does the formatting. Like some GUI tool or web interface, there's no need to format in the database itself.

No, my system "uses" UTC.
But it does display the time/date in my locale.

>REAL value using "thousands separator"
>REAL
>"thousands separator"
Separator is for string representation only

what?
create table youreafaggot (number DECIMAL);

insert into table values(9999.9);

select rowid,* from youreafaggot;

never change, Jow Forums

Attached: 1476139284716.jpg (7680x4320, 2.82M)

I must ask, where did you learn how to do that?
I spent hours trying to find that solution, and couldn't.

Or maybe I just didn't understand it when I did see it.