DB2 Regular expression REGEXP_INSTR works perfectly using host variables(pl1 program), but somehow it has issues when the input string has more than 360 characters, trailing spaces would not be a issue.
3 Info CHAR(378),
EXEC SQL
SELECT REGEXP_INSTR(:Info,
:RG_EXPR,
1,
1)
INTO :REGEXP_START
FROM SYSIBM.DUAL;
Error Message:
SQL0302N The value of a host variable in the EXECUTE or OPEN statement is out of range for its corresponding use. .SQL
STATE=22001.
Edit: Issue seems to be resovlved when I use a VAR CHAR variable instead. But this issue occurs with non-var char field with large inputs.
This is less to do with regexp_instr() than simple fundamentals.
Instead, it concerns Db2 database fundamentals, specifically the maximum length of fixed length character strings.
A fixed length character string (data type CHAR in SQL) in Db2 can occupy between 1 and 255 bytes.
A variable length character string (database type VARCHAR and others) can occupy between 1 and 32,672 bytes .
If you need longer length strings, then you need to use large objects (for example CLOB which allows up to 2gigabytes).
Please refer to the documentation for your Db2-version on your Db2 platform (z/os, i series, linux/unix/windows).
Your host variables need to reflect these rules, and your host variables must match (or be fully compatible with) the database columns or result-set columns to/from which they are assigned.
I need help on how to resolve characters of unknown type from a database field into a readable format, because I need to overwrite this value on database level with another valid value (in the exact format the application stores it in) to automate system copy acitvities.
I have a proprietary application that also allows users to configure it in via the frontend. This configuration data gets stored in a table and the values of a configuration property are stored in a column of type "BLOB". For the here desired value, I provide a valid URL in the application frontend (like http://myserver:8080). However, what gets stored in the database is not readable (some square characters). I tried all sorts of conversion functions of HANA (HEX, binary), simple, and in a cascaded way (e.g. first to binary, then to varchar) to make it readable. Also, I tried it the other way around and make the value that I want to insert appear in the correct format (conversion to BLOL over hex or binary) but this does not work either. I copied the value to clipboard and compared it to all sorts of character set tables (although I am not sure if this can work at all).
My conversion tries look somewhat like this:
SELECT TO_ALPHANUM('') FROM DUMMY;
while the brackets would contain the characters in question. I cant even print them here.
How can one approach this and maybe find out the character set that is used by this application? I would be grateful for some more ideas.
What you have in your BLOB column is a series of bytes. As you mentioned, these bytes have been written by an application that uses an unknown character set.
In order to interpret those bytes correctly, you need to know the character set as this is literally the mapping of bytes to characters or character identifiers (e.g. code points in UTF).
Now, HANA doesn't come with a whole lot of options to work on LOB data in the first place and for C(haracter)LOB data most manipulations implicitly perform a conversion to a string data type.
So, what I would recommend is to write a custom application that is able to read out the BLOB bytes and perform the conversion in that custom app. Once successfully converted into a string you can store the data in a new NVCLOB field that keeps it in UTF-8 encoding.
You will have to know the character set in the first place, though. No way around that.
I assume you are on Oracle. You can convert BLOB to CLOB as described here.
http://www.dba-oracle.com/t_convert_blob_to_clob_script.htm
In case of your example try this query:
select UTL_RAW.CAST_TO_VARCHAR2(DBMS_LOB.SUBSTR(<your_blob_value)) from dual;
Obviously this only works for values below 32767 characters.
Hi I am using postgresql 9.2 and I want to use varchar(n) to store some long string but I don't know the maximum length of character which varchar(n) supports. and which one is better to use so could you please suggest me? thanks
tl;dr: 1 GB (each character (really: codepoint) may be represented by 1 or more bytes, depending on where they are on a unicode plane - assuming a UTF-8 encoded database). You should always use text datatype for arbitrary-length character data in Postgresql now.
Explanation:
varchar(n) and text use the same backend storage type (varlena): a variable length byte array with a 32bit length counter. For indexing behavior text may even have some performance benefits. It is considered a best practice in Postgres to use text type for new development; varchar(n) remains for SQL standard support reasons. NB: varchar() (with empty brackets) is a Postgres-specific alias for text.
See also:
http://www.postgresql.org/about/
According to the official documentation ( http://www.postgresql.org/docs/9.2/static/datatype-character.html ):
In any case, the longest possible character string that can be stored is about 1 GB. (The maximum value that will be allowed for n in the data type declaration is less than that. It wouldn't be useful to change this because with multibyte character encodings the number of characters and bytes can be quite different. If you desire to store long strings with no specific upper limit, use text or character varying without a length specifier, rather than making up an arbitrary length limit.)
Searching online reveals that the maximum value allowed varies depending on the installation and compilation options, some users report a maximum of 10485760 characters (10MiB exactly, assuming 1-byte-per-character fixed encoding).
By "the installation and compilation options" I mean that you can always build PostgreSQL from source yourself and before you compile PostgreSQL to make your own database server you can configure how it stores text to change the maximum amount you can store - but if you do this then it means you might run into trouble if you try to use your database files with a "normal", non-customized build of PostgreSQL.
Which is the biggest possible String type in SQL?
TEXT? or another?
DBMS: SQLITE and MYSQL
The largest character data type in MySql is LONGTEXT (see Storage Requirements for String Types), that is capable to hold 2^32-1 bytes.
SQLite does not impose any length restrictions (other than the large global SQLITE_MAX_LENGTH limit) on the length of strings, BLOBs or numeric values. The default limit for that is 1 billion, but you can change it at compile time to a maximum of 2^31-1 (see Maximum length of a string or BLOB).
CLOB.
The SQL standard uses the name CLOB (it's feature T041-02 in SQL2008), but note that other databases may have different names for it. I think TEXT is one.
This question already has answers here:
Datatype for storing ip address in SQL Server
(12 answers)
Closed 7 years ago.
What should be the most recommended datatype for storing an IPv4 address in SQL server?
Or maybe someone has already created a user SQL data-type (.Net assembly) for it?
I don't need sorting.
Storing an IPv4 address as a binary(4) is truest to what it represents, and allows for easy subnet mask-style querying. However, it requires conversion in and out if you are actually after a text representation. In that case, you may prefer a string format.
A little-used SQL Server function that might help if you are storing as a string is PARSENAME, by the way. Not designed for IP addresses but perfectly suited to them. The call below will return '14':
SELECT PARSENAME('123.234.23.14', 1)
(numbering is right to left).
I normally just use varchar(15) for IPv4 addresses - but sorting them is a pain unless you pad zeros.
I've also stored them as an INT in the past. System.Net.IPAddress has a GetAddressBytes method that will return the IP address as an array of the 4 bytes that represent the IP address. You can use the following C# code to convert an IPAddress to an int...
var ipAsInt = BitConverter.ToInt32(ip.GetAddressBytes(), 0);
I had used that because I had to do a lot of searching for dupe addresses, and wanted the indexes to be as small & quick as possible. Then to pull the address back out of the int and into an IPAddress object in .net, use the GetBytes method on BitConverter to get the int as a byte array. Pass that byte array to the constructor for IPAddress that takes a byte array, and you end back up with the IPAddress that you started with.
var myIp = new IPAddress(BitConverter.GetBytes(ipAsInt));
Regarding this comment in the accepted answer
sorting them is a pain unless you pad
zeros.
Here's a trick for SQL Server 2008 (From Itzik Ben-Gan in this book)
with ip_addresses as
(
SELECT '131.33.2.201' AS ip_address UNION ALL
SELECT '2.12.4.4' AS ip_address UNION ALL
SELECT '131.33.2.202' AS ip_address UNION ALL
SELECT '2.12.4.169' AS ip_address UNION ALL
SELECT '131.107.2.201' AS ip_address
)
select ip_address
from ip_addresses
ORDER BY CAST('/' + ip_address + '/' AS hierarchyid)
Returns
ip_address
-------------
2.12.4.4
2.12.4.169
131.33.2.201
131.33.2.202
131.107.2.201
For space efficient storage and when the values are to be processed (matched or compared to a range), I use an int. The IP address really is just a 32 bit value.
For a simple solution where you just want to store the value to view it, I use a varchar(15) to store the string representation of the IP adress.
Don't forget about IPv6 - you need a lot more room if you need to store them - 128bits compares to IPv4's 32.
I'd go for bigint, though you will need some helper code to translate to human friendly versions.
One of my favorite articles talks about why you shouldn't use regular expressions to parse IP addresses. Most of what they're talking about is really explaining why you should be very careful with textual representations of IP addresses. I suggest you read it before deciding what datatype to use in your database, and probably also for whatever handling your app will be doing (even though the article is written about Perl, it's useful for any language).
I think in the end a 32 bit datatype (or four 8-bit datatypes) would be the best choice.
I'm reading a lot of similar questions on here, and none of the replies in this one mention the number one answer in others: "For IPv4 addresses, you may want to store them as an int unsigned and use the INET_ATON() and INET_NTOA() functions to return the IP address from its numeric value, and vice versa." I think this is what I'm going to go with in my db, unless I decide to use the php functions mentioned above.
IPV4? int? or tinyint x 4?
It really depends on whether it's just storage and retrieval or if it's going to be a ranged search criteria.
It depends on your purpose. If you want best storage and probably performance too and for the most part, store it as int, storing it as varchar etc. would cost more performance than just a simple innocent int.
You can also search by IP by having the search parameter as the desired int too.
There is a property IPAddress.Address but it's obsolete, I don't know why, since if you don't need sorting or control over the IP classes, the best way is to store it as unsigned integer (that has a max value of 0xffffffff which equals to 255.255.255.255 in decimal representation.
Using EF Core, you can use a converter to have it automatically converted to and from IPAddress.
Also the IPAddress class has a constructor that accepts a long argument.
And according to VS debugger visualizer, that IPAddress class itself stores its internal variable as one number (not byte array).
Read more on workarounds storing a unit in MS SQL Server:
4 byte unsigned int in ms sql?
Sql server 4 byte unsigned int
I've had some success with making four smallint (or whatever smallish integer datatype you prefer) columns -- one for each octet. Then, you can make a view which smashes them together as a char string (for display) or then you can write simple operators to determine who all is in what subnet etc.
It is quite fast (provided you do proper indexing) and also allows for really easy querying (no string manipulation!).
Since an IP address has 32 bits in it, can you just use a LONG to store the numerical value?
It wouldn't be as space-wasteful as using VARCHAR, but then you'd have to decode it back to an IP before you use it, every time, and the delay and overhead that costs might not be worth it.
Quoting this:
Store IP addresses in a CHAR(15) column. Depending on how much data you're storing, this can be quite wasteful (why do we need to store the dots?). I
I'm newbie # php,sql , but i think fastest way to store something in sql db is to convert it to int value and save as int.
I used function in php -
function ip_convert() {
$ip = $_SERVER['REMOTE_ADDR'];
$intip = str_replace(".","0",$ip);
return $intip;
}
And then i just replace all dots with zeros.
Then if i need use this ip from sql.. if($ip == ip_convert())
But this only if you use PHP.