The environment is SQL Server 2012. I'm about to change a clr procedure returned result column from varchar to nvarchar, but I'm not sure if the characters which can be found in varchar code page will always convert to the same character in unicode and also the other way. The bad example would be if someone would get the results from procedure with column of nvarchar and put that in database with varchar column. The question is, will they convert correctly always?
VARCHAR is specific to your system codepage. NVARCHAR holds Unicode characters. Unicode is always going to be a superset of any legacy codepage. As such, you can expect your conversions from VARCHAR -> NVARCHAR to map properly. However, if your NVARCHAR string later contains Unicode characters that are not found in your legacy codepage, the characters will be lost when converting back to VARCHAR.
When possible, you should avoid this type of conversion. Update the table column to NVARCHAR.
Related
I'm writing a Delphi program that needs to interact with data stored in a SQLite database that belongs to another program. Everything ok so far, except that I'm unable to get the date/time value from the data store in a column in the SQLite database, with the data type 'datetime'.
I do know that the data type of fields is not relevant in SQLite, and that everything is stored as strings, and perhaps that is possibly the reason why I find myself in this predicament.
Below is a sample of a few rows of the data stored in the SQLite database (column 3) vs. the corresponding date value displayed in the program (column 2) that reads and writes to this SQLite database:
1 11/7/1971 621939168000000000
2 3/17/1976 623314656000000000
3 5/4/1996 629667648000000000
4 9/21/2007 633259296000000000
5 11/17/1972 622264032000000000
6 2/7/1996 629592480000000000
7 6/13/2000 630964512000000000
My requirement: Once I read the value in column 3 from my Delphi program, how do I translate it to the same date/time value as displayed in column 2? I have tried the UnixToDateTime function, but it does not result in the same value (as column 2). Can anyone help?
Thanks in advance!
The value in column 3 is the number of 100 nanoseconds since 1/1/0001. You can convert it into a Delphi TDateTime like this:
theDate := (Value/864000000000) - 693593;
ı need to change the datatype of a column .
ALTER TABLE students
ALTER COLUMN "Dname" character varying (30) ;
I tried this but it doesn't work.
You should use this statement instead.
ALTER TABLE students
MODIFY Dname varchar2(30);
Best,
Yassine
In pl/sql, if you create a variable as varchar2(256) and then assign a 10 character string to the variable then the total memory used is 256 characters but if you declare it (4000 or more it will use only the 10 characters. Is that also true for varchar columns on a table? Or does a varchar column always allocate only what you have assigned? Thanks.
The varchar column is meant to be 'variable character' so it stores just one more character (the terminal) than the string you are storing. char, stores exactly the number of characters it is set to.
I have a rails app with a basic postgres db, but I realized that some of my columns are strings and it'd be best if they were floats. I'm trying to convert columns for latitude and longitude from varchar to floating-point.
I've tried this post Rails - gmaps4rails gem on postgres but I kept getting this error, ERROR: invalid input syntax for type double precision: "". I'm willing to try anything else, and I've seen solutions for ways to do it with postgres queries, but I'm uncertain of how to implement them. It's a straightforward problem; "-73.88537758790638" I want to become -73.88537758790638. I just can't seem to find a working solution or one that I understand how to implement.
Empty strings cannot be converted to a number for obvious reasons.
You have to account for that. Replace all occurrences with NULL or 0 or something compatible.
For the number of fractional digits in your example you want the data type numeric, not float - neither real (float4) nor double precision (float8). Those are lossy types and not exact enough. See:
Fetch records that are non zero after the decimal point in PostgreSQL
Try for yourself:
SELECT '-73.88537758790638'::real AS _float4
,'-73.88537758790638'::double precision AS _float8
,'-73.88537758790638'::numeric AS _numeric;
Result (up to Postgres 11):
_float4 | _float8 | _numeric
---------+-------------------+-------------------
-73.8854 | -73.8853775879064 | -73.88537758790638
db<>fiddle here
Display improved in Postgres 12 (more extra_float_digits by default):
db<>fiddle here
Numeric types in the manual.
Solution
Single SQL statement (replacing empty strings with NULL):
ALTER TABLE tbl
ALTER COLUMN col1 TYPE numeric USING NULLIF(col1, '')::numeric;
This is a really simple thing to do in rails using a native ORM approach:
change_column :restaurants, :column_name, ‘double precision USING CAST(column_name AS double precision)'
I have a db column for upc codes setup as a 'numeric' data type in postgres.
I generated scaffolding to input values into this table, but rails is converting the input in FLOAT for some reason,
eg, a 13 digit number entry 1234567890000 is converted to 1234567890000.0
from the logs:
INSERT INTO "upc_codes" ("upccode") VALUES (1234567890000.0) RETURNING "id"
Where is the data type for the SQL statement being set, or not set as the case may be?
What data type are using for this column? Try changing the column type to an integer in a migration:
change_column :upc_codes, :upc_code, :integer
max integer value for an mysql integer should be 2147483647 .
i will suppose this could cause an errors somewhere .
try to change the coulm into a bigint .
aniway ,from my experience is better to handle bignum using string in rails (in this manner you could saftly change db). you could always use to_i later in your code .
sorry for my english.
When you set the column type to NUMERIC are you specifying the precision/scale like this: NUMERIC(13,0)? (13 is precision, 0 is scale)
I submitted this again as an answer because I guess I commented when I should have answered.