I have a primary key in my table as NUMBER and it was populated using the following:
to_number(sys_guid(),'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')
Now how can I query the table?
Using
SELECT * FROM TABLE1 WHERE ID = 2.68819609716248E38
does not return any results
OK, so you had a raw value which you converted to number. Now you need to reverse the process.
First convert the saved number back to a string. Then apply hextoraw. When you convert from number to string, you must use a format model to request hex representation. Then you must use the fm format model modifier, and use 0 as the first digit to make sure the string keeps leading zeros; the fm modifier is needed so you don't get a space (placeholder for sign) as the first character.
Alternatively, you could compare directly to a fixed number, but the number must make sense. You show something like 2.68199...E38 as your input. Where is that coming from? Obviously not from converting a raw value to number (like you did with the sys_guid values). The value should be a 38-digit integer, with 38 significant digits; your value has only 15 significant digits, so the rest are filled with zeros. Obviously that will not match any saved values.
Related
using eloquent is it possible to save a numeric value like 012345 with the leading 0 or is the only possibility to store the value as string?
To provide more details: I'd like to store a zip-code, which can have a leading 0 in Germany. There's no possibility to always add the 0, because not all zips start with 0
Numeric datatypes do not retain leading zeros, as they are insignificant to the number you want to store. Char or Varchar is more appropriate. You could set a constraint to ensure only numeric characters are stored.
If you absolutely cannot change the data type, then another alternative is to store the number of leading zeros into another int field
So in your example you would store:
Value : 32
Leading zeros : 2
Source https://stackoverflow.com/a/23309167/5442966
012345 is not a number. It's a string. 12345 is the number. SQL Server is able to recognize that those extra zeros are not needed to define the number, so it ignores them. If you want to dispaly a value as 012345 to the application, I'd suggest doing the formatting on the application side. That way the number stored in SQL Server is still a number if you want do addition, aggregation, or other calculations. If you really have to store it as 012345, you need to convert it to a character field; char, varchar, nvarchar, nchar.
For Details
I'd like to add a large string (above 76k characters) to CLOB column in Oracle database.
I need to run a script from liquibase framework.
How can achive this?
Simple insert
INSERT INTO table_clob (clob_column) VALUES (to_Clob('string above 72000 chars...'));
with and without to_clob() method is returning exception like:
ORA-01704: string literal too long
Cannot load data from file as described here with procedure: https://oracle-base.com/articles/8i/import-clob
as I don't have priviliges to any directory
Searched google but didn't enounter any solution for my requirement.
Any advice?
UPDATE:
After hours of searching finally found a workaround here: https://stackoverflow.com/a/49817056/1622703
It is not sufficient as I need to cut the text for 3 chunks manually (with around 30k chars), but it works.
Now just need to figure our how to do it dynamically in case that the string will have vary lenghts of chars (above 10k chars for example).
A hard-coded string enclosed in single quotes is known as a string literal. An example is 'Hello world'. Another example is the very long string you are trying to insert in the table. By contrast, 'abc' || 'def' is a string expression but it is not a string literal. Similarly, to_char(sysdate, 'yyyy-mm-dd') is a string expression, but not a literal. "Literal" means constant, hard-coded text.
The issue you are facing has nothing to do with insert, or to_clob(), or the data type of columns in your table, etc. It only has to do with the string literal itself.
In Oracle, a string literal can be at most 4000 bytes long (or 32767 bytes if the database is set up with extended MAX_STRING_SIZE). PERIOD! There is no way around it.
So, the question is, how can you ever get a string as long as the one you have into a table with a CLOB column. The answer depends on how you are receiving the string in the first place. The best option would be if it came in chunked already - as a collection of strings, with a tag (an id) to keep track of which fragment belongs to which CLOB and an ordinal number (to show if it's the first chunk, the second, etc.) Then you could re-assemble them using TO_CLOB() on the first chunk, plus the concatenation operator.
If your process is to type 72000 characters at the keyboard, you will have to type 4000 of them at a time, enclose in single quotes, and use the concatenation operator (essentially doing by hand what I described above). You would also have to use TO_CLOB() on the first fragment (otherwise the concatenation will fail).
Another option is for the string to come as a value, from some application that supports long strings (something compatible with Oracle's CLOB) and that can hand over such values to the Oracle database without the need to write out the hard-coded string in full.
So, the ball is in your court. The first question is, Where is the long string coming from in the first place?
I have a table with a column in the format VARCHAR2(2000 CHAR). This column contained a row containing comma-separated numbers (ex: "3;3;780;1230;1;450.."). Now the situation has changed. Some rows contain data in the old format, but some contain the following data (ex: "BAAAABAAAAAgAAAAHAAAAAAAAAAAAAAAAQOUw6.."). Maybe it's blob or clob. How can I check exactly? And how can I read it now? Sorry for my noob question :)
The bad news is you really can't. Your column is a VARCHAR2 so it's all character data. It seems like what you're really asking is "How do I tell if this value is a comma separated string or a binary value encoded as a string?" So the best you can do is make an educated guess. There's not enough information here to give a very good answer, but you can try things like:
If the value is numeric characters with separators (you say commas but your example has semicolons) then treat it as such.
But what if the column value is "123", is that a single number or a short binary value?
If there are any letters in the value, you know it's not a separated list of numbers, then treat it as binary. But not all encoded binary values will have letters.
Try decoding it as binary, if it fails, maybe it's actually the separated list. This probably isn't a good one.
I'm new to Oracle, I'm using oracle 11g. I'm storing postal codes of UK. Values are like these.
N22 5HF
SW1 4JD
N14 8IT
N22 1JT
E1 5DP
e1 8DS
E3 8TU
I should be able to easily compare first four characters of each postal code.
What is the best data type to store these data ?
As a slight variation on Lalit's answer, since you want the outward code rather than a fixed substring of the first four characters (which could incude a space and the start of the inward code), you can create a virtual column based on the first word of the value:
postcode varchar2(8),
outward_code generated always as
(substr(postcode, 1, instr(postcode, ' ', 1, 1) - 1))
And optionally, but probably if you're using this to search, an index on the virtual column.
This assumes the post codes are formatted properly in the first place. It won't work if you don't always have the space between the outward and inward codes. And to answer your original question, the actual post code should be a varchar2(8) column to hold alphanumeric valus up to the maximum size and with the standard format.
SQL Fiddle demo.
I should be able to easily compare first four characters of each postal code.
Then keep these first four characters in a separate column. And index this column. You could keep the other characters in different column. Now, if the codes are a mixture of alphanumeric characters, then you are left with VARCHAR2 data type.
Your query predicate would like -
WHERE post_code_col = substr('N22 5HF', 1, 4)
Thus the indexed column post_code_col would be efficient in performance.
On 11g, you have the option to create a virtual column. However, indexing it would be equivalent to a function-based index. So I woukd prefer the first way as I suggested above.
It is better to normalize the table during the design phase, else the issues would start creeping in later.
In my opinion you should use varchar2 data type because this field will not going to be in mathematical calculations (they should not be int or decimal) and these fields are not big enough (so this should not be text)
I'm using integration services (SSIS), at the moment I'm getting the data from an excel source, the string Description comes with a length greater than 15 chars: the problem is that I can't find a way to truncate this data in order to save it in the database (the column database is varchar(15) and I can't change it).
I was trying to use a derived column in order to truncate the data with no success.
Add a derived column transformation and use the SUBSTRING function to get only the first 15 characters of the string. Read about the Substring function in SSIS here SUBSTRING SSIS Expression
Your expression in the derived column would look something like SUBSTRING(Description, 0, 15)