Using forward slash in SQLdeveloper is working fine on one machine but in another machine (and different DB) the pl/sql script is hanging, meaning the procedure (ends with '/') is running without stopping.
For some reason it also happens in SQL*Plus which usually is ok with '/'.
Once we are removing the '/' the issue is resolved.
what can cause it?
Related
I just ran a script in MySQL Workbench 6.3 Community.
I've set it to 'Stop Script Execution on Errors'.
There were two queries that gave errors.
The errors say 'Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.'
Ok, so I missed that. No big deal.
But after that, the script simply continued as if there were no error at all, or as if I never set 'Stop Script Execution on Errors'.
As a consequence I've lost some data. (This was a test database, so no worries there.)
The script continues after the errors:
Any idea how to make it stop executing the script?
A colleague pointed me to Edit->Preferences, SQL Editor, SQL Execution, Continue SQL script execution on errors (by default).
Continue SQL script execution on errors (by default)
This worked after restarting Workbench.
I am using execute command tag from my liquibase changesets and this inturn is configured to run the sqls in oracle instant client sql plus.
when i run a liquibase update on my changelogxml everything works fine and the liquibase update is sucessfull.I can see the changes to the table also.
But when i try to fail the update process by giving a syntax error in my sql file refered in the changeset.Liquibase still returns liquibase update sucessfull.I expected it to throw sql errors.The sql when run seperately in toad throws syntax error.What should i do to get the error displayed out.?
Datical has created a custom Liquibase change tag that executes SQL using the sqlplus command line client. It was surprisingly much more complicated that you might think.
Some of the issues we had to deal with:
we had to do things to ensure that the sql files always had certain statements in place, and never had certain other statements. This might include things like setting the schema, ensuring that the only spool commands were ones we knew about, that the script had an 'EXIT' command, and ensuring that whenever there was a SQL error that the exit code was returned.
The sqlplus executable does not return an exit code (i.e. a non-zero exit code form the native process) in all cases, and instead will write errors to an error table in the database. The table where sqlplus writes errors is called sperrorlog, and this may be what you will need to look into.
I can't really go into all the details, but just know that what you are attempting to do is neither simple nor straightforward.
I'm trying to connect to a MS SQL Server trough PHP 5.6 with an Ubuntu 16.04 server. I'm forced to use this version of PHP, in order to assure compatibility with an 'ancient' application.
I installed PHP 5.6 and its modules (pdo, pdo_mysql, readline, etc.) trough ondrej's PPA without any trouble, but I wasn't able to find and install the 'mssql.so' module package needed for the application I'm trying to make work.
That's why I decided I would use ODBC (and PDO_ODBC) drivers in order to connect to the database.
In order to do so, I installed freetds with unixodbc and configured my files like this :
'odbcinst.ini' file :
'odbc.ini' file :
and finally the 'freetds.conf' file :
Ok, I guess all my files are well configured, but the next part starts to be a bit weird, let me explain you : when I try to connect to the MS SQL database using tsql and not giving the password in option but typing it when asked, the connexion works :
But when I try to give the same password as an option (-P), it doesn't work (I tried it at least 10 times with the correct password) !!!
--> tsql failed to open a session for the user 'WIPSOS-PHP'
The same problem happens when I try to use isql with one of my connectors I configured in the 'odbc.ini' file :
It seems to be related to the password, but I can't find the problem, can you please help me ?
I found a partial answer, and it was effectively related to the password: it seems like special characters are not well interpreted when present in the password given for the -P option of the tsql command.
Therefore, depending on you shell, you have to escape these characters in the string which completes an option. In my case, using bash, I had to use the '\' to escape the special character :
tsql -S hostname -D Database -U User -P pa\$\$word
And it now works!
But when I try to escape the special characters with '\' in the 'odbc.ini' file, it still doesn't seem to work :
My next question is : 'How to escape a special character in a '.ini' file ?' or 'Is there something wrong in my configuration ?'
EDIT: I know it was a long time ago, but I had a configuration problem related to the hostname in the "freetds.conf" file. In fact, I was using the server's local network DNS name instead of its IP adress(which works).
I hope my issue will at least help some people, it isn't easy to deal with TSQL and FreeTDS...
Setup:
Ubuntu 12.04 Server installed via VMWare quick install
PostgreSQL 9.1
ElasticSearch 0.90
Mono 3.2.1
Rails 4
Nginx 1.4.2 + Passenger 4.0.16
I have a C# program that on start writes a new ElasticSearch index and points the alias that is used by the rails applications to it, the program then keeps going and watches a redis instance for things to update.
There is another C# program that scrapes data from web pages, once scraped they are put into Postgresql and the index writer above is notified via Redis. Those pages have varying encodings and are converted to UTF-8.
The first appearance of this bug was when I made a mistake and encoded data that was already UTF-8 as UTF-8 again.
Investigation
Now I thought that I obviously have some data corruption going on but the weird thing is: The umlauts are only corrupted when I start the indexing mono process from rails via nohup, if I kill this process and manually start it from the command line it works perfectly fine.
When I do a backup/restore of the database it works again from web interface but once the server is rebooted the umlauts are again replaced with ?? when starting the mono process from the web interface.
The first thing I did was to purge the affected rows from the database and scrape the data again (without encoding it twice), that didn't help and since the error only appears when running it as non-interactive via nohup from the rails application I assumed it is because of the locale setting so I changed that in both, /etc/defaults/locale and /etc/environment to en_US.UTF-8 and en_US:en but that did not help either.
I really have no idea what else I can do or what exactly causes this error, any help would be appreciated.
edit: I forgot to clarify the most important part, when umlauts are replaced with ?? ALL umlauts are replaced in every single document in the index.
Put this in the script that you use to start your process:
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
The reason that your script only picks up the UTF-8 when you start things manually is that these things are not system wide. I've run into this with jruby and init.d scripts before and the solution is to not rely on defaults for this.
I get this exception in PostgreSQL:
org.postgresql.util.PSQLException: ERROR: could not access file "$libdir/plpgsql": No such file or directory
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1721)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1489)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:193)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:236)
at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:205)
I searched a lot and most solution points to a wrong installation. But this is my test db which has been running without issues for a long time. Also inserts are working. Issue occurs only on select queries.
Apparently, you moved your PostgreSQL lib directory out of place. To confirm this, try the following in psql:
> SET client_encoding TO iso88591;
ERROR: could not access file "$libdir/utf8_and_iso8859_1": No such file or directory
If you get an error message like this, then my theory is correct. You'll need to find out where those files ended up, or you can reinstall PostgreSQL to restore them.
To find out what $libdir is referring to, run the following command:
pg_config --pkglibdir
For me, this produces:
/usr/lib/postgresql
I have the same problem: the other postgres server instance (8.4) was interfering with the 9.1 one; when the 8.4 instance is removed it works.
the other instance can sometimes be removed from the system while still running (e.g. you do a gentoo update and a depclean without stopping and migrating your data). so the error seems particularly mysterious.
the solution is usually going to be doing a slot install/eselect of the old version (in gentoo terms, or simply downgrading on other distros), running its pg_dumpall, and then uninstalling/reinstalling the new version and importing the data.
this worked pretty painlessly for me