I have a perl script that is inserting records from a text file into our database. Whenever the record has a multibyte character like "RODR_Í_GUEZ". I receive the error ORA-01461, however i'm nowhere near the 4000 characters to switch from varchar2 to long
setting:
$ENV{NLS_CHARACTERSET} = 'AL32UTF8';
before connecting doesn't seem to help.
Using a java client (SQuirreL SQL) and manually writing the INSERT INTO statement inserts the record just fine, so i'm sure it's not how the database is configured.
Any thoughts?
You probably want to set the NLS_LANG environment variable. For Unix-ish systems, there is a script supplied in $ORACLE_HOME/server/bin called nls_lang.sh to output a reasonable value for your system, based on the LANG environment variable.
e.g. for my system (LANG=en_GB.UTF-8) the equivalent Oracle setting is
NLS_LANG=ENGLISH_UNITED KINGDOM.AL32UTF8
More info: http://forums.oracle.com/forums/thread.jspa?threadID=381531
Sergiusz's post there says practically all you need to know: I'll just add that the Perl DBD::Oracle driver is OCI-based, and the pure-Java JDBC driver isn't, hence they work differently in the same environment.
Related
For ex, I have a query in postgreSQL such that "product_version=:productVersion".
It's giving me a syntax error.
It's giving you a syntax error because it makes no sense as SQL, and is invalid syntax.
(Please always show the exact text of error messages*)
Since inserting the string literal :productVersion doesn't make much sense, e.g.
product_version=':productVersion'
you might be using the psql command line client and trying to substitute a client variable. If so, you need to use a quoted substitution, e.g.:
product_version=:'productVersion'
but this only works for psql. Not Rails and the Pg gem, not JDBC, not PHP, not psycopg2, nothing but psql.
If that's not what you meant, then either you are using a programming language with placement parameters and using the wrong parameter syntax for your language, or you are attempting to use the psql command line client's variable substitution and aren't using psql. Impossible to guess what you mean unless you specify the language/tools used.
Look up the placement parameter syntax for your programming language and database driver. Make sure you're using the right one.
I'm new to this program and I found a problem when try to log in to start my programming. I get an error as shown in the figure below and stuck here for quite some time and I wonder it was came out with such strange characters. Hopefully could receive some recommendations and solutions over here.
You most likely have an encoding problem.
As you said in chat, your database encoding is UTF-8, while your shell encoding is CP-1252 ("Latin-1").
You need to switch your Terminal to UTF-8 (if thats possible on windows).
But most likely you want to use pgAdmin for your work. As long as you don't have a very specific reason to use the shell, its by far more convenient to use pgAdmin.
how do i properly handle unicode issues in PHP. Do i just set UTF-8 as a parameter to any function that needs it or do i set it as the locale somewhere in the bootstrap file once? How do it affect mysql etc
There's no way to set a global encoding in PHP. The best you can do is, always use the mb_ family of functions, and try to always be explicit about the encoding you want to use.
As for mysql, in particular, you can make sure that it connects using utf-8, usually by calling a set encoding method/function right after connecting or in the constructor if you're using pdo (see http://ar.php.net/manual/en/pdo.construct.php.)
Using utf-8 with PHP requires some discipline, but, it's definitly worth it. Hope any of this helps.
The Perl module Term::Screen has a method for inserting a character and deleting a character. Both of these methods have an accompanying method to check if the interface allows for such actions [ic_exists() and dc_exists()]. I'm running this script through a ssh session and the ic_exists and dc_exists are returning 0, not available. What do I need to do to enable the insert character and delete character for this module?
Make sure that the TERM in your ssh environment is set to something that supports those functions (and is compatible with your terminal).
Try adding
print "$ENV{TERM}\n";
to your script to see what terminal it thinks it's talking to.
Does a command line tool ship with Informix 11.5 similar to SQLCMD for SQL Server?
If yes, how do I connect to a remote server and perform regular SELECT/INSERT/UPDATE queries using it?
As Michal Niklas says, the standard tool provided with IBM Informix Dynamic Server (colloquially IDS or even just Informix) is DB-Access. However, it is distributed only with IDS itself, not with the Informix Client SDK (CSDK) or Informix Connect (I-Connect) products.
If you want to access IDS from a machine that does not have IDS installed, you need either CSDK or I-Connect on the machine, and some other software - perhaps the original (pre-Microsoft by a decade and more) version of SQLCMD. This is what I use - and have used in various versions over the last (cough, splutter, ouch) twenty-two years or so; I wrote it because I didn't like the command line behaviour of a program called isql (part of the product Informix SQL), which was the pre-cursor to DB-Access. (Lot's of history - not too important to you.)
Usage - SQLCMD has more options than you know what to do with. The basics are simple, though:
sqlcmd -d dbname#dbserver -e 'select * from table' -x -f file.sql
This connects to a database called 'dbname' at the database server known as 'dbserver' as specified in the sqlhosts file (normally $INFORMIXDIR/etc/sqlhosts). The '-e' indicates an SQL expression - a select statement; the results will be printed to standard output in a strict format (Informix UNLOAD format), one logical line per record. The '-x' turns on trace mode; the '-f' option means read the named file for further commands. The '.sql' extension is not mandatory (beware: DB-Access requires the '.sql' extension and will add it for you). (Arguments not prefixed by either '-e' or '-f' are interpreted heuristically; if it contains spaces, it is SQL; if it does not, it is a filename.) The '-H' option prints column headings (labels) before a result set; the '-T' option prints the column types (after the headings, before the results). The '-B' option runs in benchmark mode; it turns on trace, prints the statement, the time when the statement started, and times how long it took. (Knowing when the statement started is helpful if the SQL takes many minutes to run - as it can in benchmarking scenarios). There are controls over the output format (including CSV and even variant of XML - but not an XML using namespaces) and date format, and so on. There are 'built-in' commands to redirect input and output and errors; most command line options can also be used in the interpeter, etc. SQLCMD also provides a history mechanism; it saves SQL statements and you can view, edit or rerun them. In conjunction with output redirection, you can save off a list of statements executed, etc.
The only gotcha with SQLCMD is that it is not currently ported to Windows. It did work on Windows once upon about 6 or 7 years ago. Since then, Microsoft's compilers have gotten antsy about non-MS API functions, insisting that even if I ask for them by name (by requesting POSIX functionality), the functions must be prefixed by an underscore, and by deprecating a bunch of functions that can be used safely if you pay attention to what you are doing (but, regrettably, can be abused by those who are not paying attention, and there are more inattentive than attentive coders around, it seems) - I mean functions like 'strcpy()' which can be used perfectly safely if you know the size of the source and destination strings before you call it. It is on my list of things to do - it just hasn't been done yet because it isn't my itch.
There is also another Open Source tool called SQSL that you can consider. It has some advantages over SQLCMD (conditional logic, etc) but I think SQLCMD has some advantages over SQSL.
You could also consider whether Perl + DBI + DBD::Informix + dbish would work for you.
Try DB-Access
...
DB–Access provides a user interface for entering, executing, and debugging Structured Query Language (SQL) statements and Stored Procedure Language (SPL) routines...