I have installed unixOdbc on my Ubuntu PC.
I have configured DSN 'mydsn' and it works just fine with isql.
> isql mydsn
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL> insert into users values('1', 'user', 'password');
SQLRowCount returns 1
It means postgres odbc driver and data source are installed and configured properly. I couldn't connect isql before everything was configured.
If I am trying to execute the same statement with Poco::ODBC it fails with the exception.
E [2016-06-25 13:41:48.117] Application {3}: ODBC handle exception: SQLCloseCursor(): Connection:Not applicable
Server:Not applicable
===========================
ODBC Diagnostic record #1:
===========================
SQLSTATE = 200
Native Error Code = 0
[nxDC[rvrMngrIvldcro tt
Here is my code
using Poco::Data::ODBC::Connector;
...
Connector::registerConnector();
_pool = new SessionPool(Connector::KEY, "DSN=mydsn;", size, size);
Session session(_pool->get());
session << "insert into users values('2', 'user', 'password');", now;
I tried to google SQLCloseCursor exception but it gives me a lot of irrelevant results. I haven't tried to debug (break points and so) this yet.
Any suggestion of where to start?
I have upgrade ubuntu 14 to ubuntu 16.04 and the problem disapperd. It looks like some bug in unixODBC 2.24 while working with Postgres 9.3.
Related
I have imported a local PostgreSQL database to a managed cluster on Digital Ocean. It will be used with a Python app that will also be hosted on Digital Ocean. I used pg_dump and pg_restore to achieve the import. Now, to make sure the import was successful, I am running some psql queries and commands via my MacOS terminal app that is set up with zsh and it connects via a shell script that prompts me for host, database name, port, user and password. I am successful in connecting to the managed cluster this way, and I can execute some queries with no problem, while others are causing errors. For example:
my_support=> \dt
List of relations
Schema | Name | Type | Owner
--------+----------------------+-------+---------
public | ages | table | doadmin
public | articles | table | doadmin
public | challenges | table | doadmin
public | cities | table | doadmin
public | comments | table | doadmin
public | messages | table | doadmin
public | relationships | table | doadmin
public | topics | table | doadmin
public | users | table | doadmin
(9 rows)
my_support=> \dt+
sh: more: command not found
my_support=>
Also:
my_support=> SELECT id,sender_id FROM messages;
id | sender_id
----+-----------
1 | 1
2 | 2
3 | 4
4 | 1
5 | 2
(5 rows)
my_support=> SELECT * FROM messages;
sh: more: command not found
my_support=>
So the terminal app seems to dislike certain characters, such as * and +, but I can't find any documentation that tells me I should escape them, or how. I tried backslash in front of them, but it did not work. And what's more confusing is that these very same queries are successful when I connected to my LOCAL copy of the database, using the very same terminal app, launched from the very same shell script.
In case it's helpful, here's what I see in the CLI when I connect:
psql (14.1, server 14.2)
SSL connection (protocol: TLSv1.3, cipher: <alphanumeric string here>, bits: 256, compression: off)
Type "help" for help.
my_support=>
Does it matter that my local PostgreSQL version is 14.1 and the server is 14.2? I'm assuming the "server" refers to the hosted environment, but it seems like something as basic as "SELECT * FROM" should not be version-dependent.
Ultimately what matters is whether my Python app (which uses psycopg library to talk to PostgreSQL) can run those queries, and I haven't test that yet. But it sure would be handy to test things on the managed cluster using my local terminal app.
BTW, I have an open ticket with Digital Ocean to answer this question, but I find SO to be faster and more helpful in most cases.
psql is trying to use a pager to display results that are longer than the number of lines in the terminal. The error message
more: command not found
indicates that the pager (more) it tries to use is not available. You can turn off the use of a pager:
\pset pager off
or set a different command to be used as the pager. See the manual for details
I am using orientdb community edition 1.7.9 on mac osx.
Database Info:
DISTRIBUTED CONFIGURATION: none (OrientDB is running in standalone
mode)
DATABASE PROPERTIES
NAME | VALUE|
Name | null |
Version | 9 |
Date format | yyyy-MM-dd |
Datetime format | yyyy-MM-dd HH:mm:ss |
Timezone | Asia/xxxx |
Locale Country | US |
Locale Language | en |
Charset | UTF-8 |
Schema RID | #0:1 |
Index Manager RID | #0:2 |
Dictionary RID | null |
Command flow:
create cluster xyz physical default default append
alter class me add cluster xyz
move vertex #1:2 to cluster:xyz
Studio UI throw the following error:
014-10-22 14:59:33:043 SEVE Internal server error:
com.orientechnologies.orient.core.command.OCommandExecutorNotFoundException:
Cannot find a command executor for the command request: sql.MOVE
VERTEX #1:2 TO CLUSTER:xyz [ONetworkProtocolHttpDb]
Console return a record as select does. I do not see error in the log.
I am planning a critical feature by using altering cluster for selected records.
Could anyone help on this regard?
Thanks in advance.
Cheers
move vertex command is not supported in 1.7.x
you have to use switch to 2.0-M2
The OrientDB Console is a Java Application made to work against OrientDB databases and Server instances.
more
I'm at a loss, I'm having issues creating a stored proc in my local Postgres server (postgres.app, Mac OS X 10.7), as so
$ psql
psql (9.3.0)
Type "help" for help.
dchaston=# CREATE OR REPLACE FUNCTION table_update()
dchaston-# RETURNS TRIGGER AS $$
dchaston$# BEGIN
dchaston$# NEW.last_edit = now();
dchaston$# RETURN NEW;
dchaston$# END;
dchaston$# $$ language 'plpgsql';
ERROR: could not access file "$libdir/plpgsql": No such file or directory
I've checked the following:
Languages installed:
dchaston=# select * from pg_language;
lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
---------+----------+---------+--------------+---------------+-----------+--------------+--------
internal | 10 | f | f | 0 | 0 | 2246 |
c | 10 | f | f | 0 | 0 | 2247 |
sql | 10 | f | t | 0 | 0 | 2248 |
plpgsql | 10 | t | t | 12019 | 12020 | 12021 |
(4 rows)
lib directory (and pkglibdir just in case):
$ pg_config --libdir
/Applications/Postgres.app/Contents/MacOS/lib
$ pg_config --pkglibdir
/Applications/Postgres.app/Contents/MacOS/lib
File present:
$ cd /Applications/Postgres.app/Contents/MacOS/lib; ls plpg*
plpgsql.so
DLSUFFIX set correctly:
lib/pgxs/src/Makefile.shlib:135: DLSUFFIX = .so
Have tried uninstalling and reinstalling, but made no difference. Any ideas?
Did you install multiple instances (multiple versions or multiple instances of the same version) of Postgres on the same box? Standard Postgres is not fit for that. Debian or Ubuntu have additional infrastructure to allow multiple versions in parallel. I don't know about OS X, though.
In standard Postgres the path for $libdir is compiled into the program. Multiple versions do not get along.
When you execute pg_config --pkglibdir, make sure it's the one associated with your installation. Run:
which pg_config
Minor notes:
9.3.0? It's recommended to always upgrade to the latest point-release, which is 9.3.2 at the moment. Maybe a current source fixes your problem.
Also check your settings whether you are using the $libdir you think you are using:
SELECT * FROM pg_settings WHERE name ~~* '%lib%';
Don't quote the language name 'plpgsql' (though it's tolerated). It's an identifier: plpgsql.
Use the plpgsql assignment operator :=. = is undocumented but tolerated.
Since Postgres 9.4 both := and = are documented.
Otherwise your function definition is fine. That's not the root of the problem:
CREATE OR REPLACE FUNCTION table_update()
RETURNS trigger AS
$func$
BEGIN
NEW.last_edit := now();
RETURN NEW;
END
$func$ LANGUAGE plpgsql;
This one is related to the accepted answer.
I started getting the problem with libdir on MacOS Catalina 10.15.7 while doing the brew update as the brew update failed in between and I noticed that Postgresql was one of the many packages that it was trying to update and the above answer provided a good hint about multiple installations.
I verified that there weren't any additional versions of postgresql installed on my system. So a simple restart of the service did the trick for me:
brew services restart postgresql#10
I use FreeBSD and found a simple way to solve the problem, just copied the library from another server and pasted it into /usr/local/lib/postgresql/, which is the way $libdir. Although the versions of PostgreSQL are different, everything is working and I had no problems again.
the server that a magento install was on crashed for (currently reason unknown) and now the backend is inaccessible. I either get no error or I get access denied. I am able to preform the password reset.
I have tried:
clearing the browser cookies and cache
clearing the session, tmp and cache folders in magento
using the magento database repair tool - no errors were found
creating a new user manually in the admin_users table (this gets access denied)
rebooting the server again (last resort but still no)
The main admin user gets a redirect loop.
Any ideas are welcome, I am now stumped.
EDIT:I am really after any way to recover a magento admin login? or failing this any way to export the data (without exporting the bugged section)
I have employed a hack in one of the core magento files detailed here: http://blog.chapagain.com.np/magento-admin-login-problem/
I have had to comment out lines in "app/code/core/Mage/Core/Model/Session/Abstract/Varien.php":
(please note this is for 1.6 - check link posted for advice on 1.4)
$cookieParams = array(
'lifetime' => $cookie->getLifetime(),
'path' => $cookie->getPath()//,
//'domain' => $cookie->getConfigDomain(),
//'secure' => $cookie->isSecure(),
//'httponly' => $cookie->getHttponly()
);
also line 104 comment out :
//call_user_func_array('session_set_cookie_params', $cookieParams);
It seems to be when the server went down something happened to the session, as the new install also failed.
You can get your data by performing a database backup via cPanel or mysqldump via SSH access. Your hosting provider should be able to help you. Additionally, you can unzip the admin files from your Magento installed version. Download it to your computer and unzip the installation... then re-zip the folder for app/design/adminhtml ... upload and unpack this on your website in the proper place, and this will reinstall the PHP pages.
Double check the file app/etc/local.xml this usually has the database login stored in it.
Inside the mysql database for your magento installation, there is the table core_config_data and in it, some path values might interfere with using admin if intentionally set incorrectly:
mysql> select config_id, path, left(value,30) from core_config_data WHERE path LIKE '%admin%';
+-----------+-------------------------------------------+--------------------------------+
| config_id | path | left(value,30) |
+-----------+-------------------------------------------+--------------------------------+
| 50 | dev/translate_inline/active_admin | 0 |
| 220 | web/secure/use_in_adminhtml | 0 |
| 687 | admin/startup/page | catalog/products |
| 690 | admin/security/use_form_key | 0 |
| 691 | admin/security/use_case_sensitive_login | 1 |
| 692 | admin/security/session_cookie_lifetime | 36000 |
| 745 | admin/url/use_custom | 0 |
| 746 | admin/url/custom | |
+-----------+-------------------------------------------+--------------------------------+
I'm having issues connecting to a sql server database from an openbsd box using unixODBC. When I use isql I get through just fine:
$ isql localProdSqlServer jegdemir GBE#oct
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL>
so I know the DSN is setup and unixODBC is working properly. However when I crack open clisp and try to connect using plain-odbc I can't get there:
$ clisp
<..snip..>>
[1]> (asdf:oos 'asdf:load-op :plain-odbc)
<..snip..>
[2]> (setf *con* (plain-odbc:connect "localProdSqlServer" "jegdemir" "GBE#oct"))
*** - [unixODBC][FreeTDS][SQL Server]Unable to connect to data source, error
code 0, State: S1000.
The following restarts are available:
ABORT :R1 Abort main loop
Break 1 [3]>
I'm fairly new to lisp so I'm having a bit of trouble diagnosing the issue. Any help would be most appreciated.
Depending on how plain-odbc works, you may need to specify a DSN in /etc/odbc.ini, something like:
[localProdSqlServer]
Driver = FreeTDS
Description = localProdSqlServer TDS driver (Sybase/MS SQL)
Trace = No
Servername = localProdSqlServer
Database = DATABASE_NAME
As an alternative, the CLSQL library has an ODBC backend that supports connection strings:
(clsql:connect '("friendly-server-name" "friendly-username" ""
:connection-string "DRIVER={FreeTDS};SERVER=localProdSqlServer;DATABASE=DATABASE_NAME;UID=jegdemir;PWD=GBE#oct;PORT=1433;TDS_Version=8.0;APP=clsql")
:database-type :odbc)
At work I use CLSQL to connect to SQL Server all the time.