I need to automatize sqlserver scripts from a linux environment.
I saw Microsoft released a linux version of its ODBC driver, that also includes sqlcmd for linux. Though, it's only available for redhat.
I found a few tutorials to force installation on several other linux versions (including debian), but they seem to be out of date : many points are wrong or -- probably -- not suited anymore.
I also tried to install and run sqsh, but I got an error trying to connect, and miss the guides to help configure it
sqsh -S xy.zk.lm.opqr -U sas -D myDB
sqsh-2.1.7 Copyright (C) 1995-2001 Scott C. Gray
Portions Copyright (C) 2004-2010 Michael Peppler
This is free software with ABSOLUTELY NO WARRANTY
For more information type '\warranty'
Password: ...
Msg 18456, Level 14, State 1
Server 'AUB-DB-QUALIF\SQLEXPRESS', Line 1
â–’chec de l'ouverture de session de l'utilisateurâ–’'sas'.
Open Client Message
Layer 0, Origin 0, Severity 78, Number 34
Adaptive Server connection failed
Since I miss skills using linux, I may not see the "obvisous" way to do it. Thus, if you have any - up-to-date - tip or trick to help run sqlserver as a command line under linux, I'll read you with great attention!
Thanks in advance.
Today 2016-11-17 Microsoft released a public preview of SQLServer for Linux (supporting Linux, Mac, Docker,... ) may be you chan use the any of the new versions with the benefits of SQLCMD.
SQL Server for Linux
Related
SQL syntax - check the manual that corresponds to your MySQL server version for the right syntax to use near 'RECURSIVE __tree
Error log
mysql -V
mysql Ver 14.14 Distrib 5.7.23, for Linux (x86_64) using EditLine wrapper
I get this error when I create a test plan. Can you please help me take a look?
I'm using latest kiwi-tcms docker image.
Posted error logs are linked below: enter link description here
Your MySQL version seems to be supported. However make sure to disable ONLY_FULL_GROUP_BY mode which is enabled by default.
I have to install DB2 PHP driver on Centos 8 for make requests to IBMi (AS400) with PHP 7 and nginx, I try to find a guide but unfortunately i can't find anything.
So I ask you, do you have a link or tips for this ?
Thanks.
You will most likely want to use the IBM i Access ODBC driver.
IBM i Access for Linux: Open Database Connectivity
There are a few options depending on how much you want to spend.
ODBC - This is likely going to be your least expensive option. You can get the drivers from the IBM i Access product mentioned by jamesallman. The IBM customer likely already has IBM i Access Client Solutions, and would already be licensed to use the driver. If you don't have the Linux drivers, here is a starting point.
IBM_DB2 / PDO_DB2 - both of these need a DB2 client. The client required by IBM i is provided with the DB2 Connect product. If you don't already have a license for that, it is also available from IBM, but it is in the "If you have to ask, it's too expensive" category.
I want to replicate postgresql data of windows server to linux server, I know how to replication between same operating systems but that method is not working with windows and linux. If yes what would be the better way to do this?
You cannot use streaming replication between different operating systems.
Look at the PostgreSQL Wiki for a list of replication solutions. Some of them should work for you.
From PostgreSQL v10 on, you could consider logical replication.
Done this using Postgresql 9.5.21 as master on Windows 2012 R2 and slave on Ubuntu 14.04.
You have to take care about a few things:
most similar CPU (page size, architecture, registers). So, you can't mix 64/32bit, or using CPU with different endianess or page size;
same endianess also for the O.S.: both 32 or 64 bit;
same major version of PG: 9.5.x with same or other 9.5.x version (that's for streaming replication, that I'm using, Logical Replication works with different versions of PG);
So, I find an already installed PG on Windows Server. Edit postgresql.conf to enable replica and PITR, and pg_hba.conf to allow connection.
Then moved on Ubuntu and, with PG stopped, I fetched from the master with:
pg_basebackup -D /tmp/db/ -X stream -R -U postgres -h ip-master
Then modified configuration and replaced data directory with /tmp/db.
Start slave, and is up and running, but look at this:
2020-03-18 21:05:31.598 CET [44640] LOG: database system is ready to accept read
only connections
2020-03-18 21:05:31.631 CET [44645] LOG: started streaming WAL from primary at 36/C2000000 on timeline 1
2020-03-18 21:05:31.905 CET [44646] [unknown]#[unknown] LOG: incomplete startup packet
2020-03-18 21:05:32.416 CET [44649] postgres#postgres FATAL: database locale is incompatible with operating system
2020-03-18 21:05:32.416 CET [44649] postgres#postgres DETAIL: The database was initialized with LC_COLLATE "Italian_Italy.1252", which is not recognized by setlocale().
2020-03-18 21:05:32.416 CET [44649] postgres#postgres HINT: Recreate the database with another locale or install the missing locale.
Here's the funny thing: replication works, but you can't connect to the databases.
Anyway, if you raw copy the data dir on Windows, it works like a charm.
Of course, if you re-create the cluster with UTF-8, there's no problem at all.
n.b.: thanks a lot to incognito and ilmari on official IRC PG channel for the hints.
When i attempt to drop an assembly I receive this error:
DROP ASSEMBLY [test.Sql.Clr]
Msg 701, Level 17, State 13, Line 1
There is insufficient system memory in resource pool 'default' to run this query.
I am running Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1).
The problematic assembly has a blank clr_name when I run sys.assemblies, and contains one dependant assembly that was replaced correctly (the problem occurred when trying to load a newer assembly)
select name, clr_name from sys.assemblies
test.Sql.Clr.Models test.sql.clr.models...
test.Sql.Clr
Has anyone seen this issue or know how to resolve it?
John
With Steve's help I was able to clean this up as follows: enabled direct access to system tables using the techniques in the link (start SQL in single user mode using the -m argument, run a sqlcmd in direct to administrator mode using -A flag). We manually cleaned out all references to the corrupt CLR by looking at sp_helptext on sys.assemblies and sys.assembly_files. We had to clean quite a few tables, and could not load the assembly properly until they all the corrupt entries were removed.
Hi I have configured the DSN settings for vertica in Ubuntu 10.10 32 bit version machine.
The settings are all fine and I have cross checked them.
Here is my odbc.ini file:
[VerticaDSN]
Description = VerticaDSN ODBC driver
Driver = /opt/vertica/lib/libverticaodbc_unixodbc.so
Servername = myservername
Database = mydbname
Port = 5433
UserName = myuname
Password = *******
Locale = en_US
Similarly I have a odbcinst.ini file.
when I run the command: isql -v VerticaDSN I get the following error:
[S1000][unixODBC][DSI] The error message NoSQLGetPrivateProfileString could not be found in the en-US locale. Check that /en-US/ODBCMessages.xml exists.
[ISQL]ERROR: Could not SQLConnect.
I have tried everything but I am not able to decipher this error.
Any help will be greatly appreciated.
You may be missing the Driver configuration section. Edit or create the file /etc/vertica.ini with the following content:
[Driver]
DriverManagerEncoding=UTF-16
ODBCInstLib=/usr/lib64/libodbcinst.so
ErrorMessagesPath=/opt/vertica/lib64
LogLevel=4
LogPath=/tmp
More information can be found in the Vertica Programmer's Guide in the section "Location of the Additional Driver Settings".
Searching the Internet about this issue I have seen that tons of people have been able to connect with tsql but not with isql or osql (which uses isql). I have had this same issue and have been researching and testing for the last week trying to figure out what the issue is. The thing is everyone has approached it from the angle of the ODBC when what I think it is is something to do with the Windows server or sql server config. I checked the logs on the windows server and see that the machine running the ODBC has hit it and tried to log in repeatedly but has not been able to. In the event viewer there are tons of entries showing the same thing, that the client machine is trying to log into SQL Server but is being refused by the host machine. That is the angle I am focusing on now and where I think the problem lies. If I get this resolved I will post again letting everyone know what I found out about this problem.
Thanks,
From the error we can see you are using unixODBC and I presume "DSI" is what Vertica calls itself as ODBC error text is formatted with entries in [] from left to right as the path though the different components (see Example diagnostic messages).
I presume that message should be "No SQLGetPrivateprofileString could be found". SQLGetPrivateProfileString is an API provided by the ODBC driver manager to read entries from the odbc.ini file. I believe it should be found in the libodbcinst.so shared object however, some distributions (e.g., Ubuntu/Debian) strip symbols from shared objects so it is difficult to verify this.
In your DSN, the driver is the file "/opt/vertica/lib/libverticaodbc_unixodbc.so". Although it is more usual to name the driver in the odbc.ini and add an entry to the odbcinst.ini file your DSN looks ok. e.g.:
/etc/odbcinst.ini:
[Easysoft ODBC-SQL Server SSL]
Driver=/usr/local/easysoft/sqlserver/lib/libessqlsrv.so
Setup=/usr/local/easysoft/sqlserver/lib/libessqlsrvS.so
Threading=0
FileUsage=1
DontDLClose=1
/etc/odbc.ini:
[SQLSERVER_SAMPLE_SSL]
Driver=Easysoft ODBC-SQL Server SSL
Description=Easysoft SQL Server ODBC driver
.
.
See in the above example doing it this way allows you to specify additional options associated with the driver like Threading (and a quick search on the net suggests Vertica can use Threading=1 which is less restrictive if using a threaded program) and DontDLClose. However, as I said things should work as you have them now.
Now the next bit depends on your platform and I didn't notice if you specified one. You need to examine that shared object for your ODBC Driver and see what it depends on. On Linux you do something like this:
$ ldd /usr/local/easysoft/sqlserver/lib/libessqlsrv.so
linux-gate.so.1 => (0xb76ff000)
libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 (0xb75fe000)
libesextra_r.so => /usr/local/easysoft/lib/libesextra_r.so (0xb75fb000)
libessupp_r.so => /usr/local/easysoft/lib/libessupp_r.so (0xb75de000)
libeslicshr_r.so => /usr/local/easysoft/lib/libeslicshr_r.so (0xb75cd000)
libestdscrypt.so => /usr/local/easysoft/lib/libestdscrypt.so (0xb75c8000)
libm.so.6 => /lib/libm.so.6 (0xb75a2000)
libc.so.6 => /lib/libc.so.6 (0xb7445000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb743b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7421000)
/lib/ld-linux.so.2 (0xb7700000)
libdl.so.2 => /lib/libdl.so.2 (0xb741d000)
which shows this ODBC driver depends on libodbcinst.so.1 and the dynamic linker found it. I imagine your Vertica driver should look similar in this respect although it is possible the Vertica driver dynamically loads this shared object itself on first being loaded. Either way, it looks like the Vertica driver cannot find the symbol SQLGetPrivateProfileString which is in libodbcinst.so so make sure a) you have libodbcinst.so b) your dynamic linker knows about it (how this is done depends on your platform - on Linux see /etc/ld.so.conf and LD_LIBRARY_PATH and the man page for ld.so) c) run ldd (or equivalent) on it to make there are no missing dependencies.
The vertica.ini file is probably where the driver stores driver specific configuration - some drivers do this. If the format of this file is like the odbc ones above it may also use SQLGetPrivateProfileString for this file as you can tell that ODBC API which file to use.
Beyond this I've no more ideas other than contact vertica.
Arun -- if you can let me know the version of the database and the version of the driver I can get you more detail. Also, I might try posting this on the official Vertica community forum.
http://my.vertica.com/forums/forum/application-and-tools-area/client-drivers/
If I had to guess what your issue is I think it might be related to this post :
http://my.vertica.com/forums/topic/odbc-on-linux-issue/
... specifically the comment at the end about 'ODBCInstLib'.