I've been doing some Sybase stuff on Linux and have bcp in's and out's working great. Here's my working bcp out on linux:
bcp drd02.dbo.APPL_ENVIRONMENT out APPL_ENVIRONMENT.bcp -U sa -P SyAdmin -n
When trying the same in Windows, I get the following error:
ct_connect(): network packet layer: internal net library error: Net-Lib protocol
driver call to connect two endpoints failed
Here's a few pertinent details:
I can connect to my server via iSQL GUI. Its shown as Sybase157 0.0.0.0 5000 and my Drd02 database is online and available.
Contents of the c:\sybase\ini\sql.ini are (I added the drd02 lines):
[Sybase157_XP]
master=NLWNSCK,0.0.0.0,5001
query=NLWNSCK,0.0.0.0,5001
drd02=NLWNSCK,0.0.0.0,5001
[Sybase157]
master=NLWNSCK,0.0.0.0,5000
query=NLWNSCK,0.0.0.0,5000
drd02=NLWNSCK,0.0.0.0,5000
[Sybase157_JSAGENT]
master=NLWNSCK,0.0.0.0,4900
query=NLWNSCK,0.0.0.0,4900
The environment variables are:
%DSQUERY%=Sybase157
%SYBASE%=c:\Sybase
No matter what I try, it's just not connecting. I'd be happy for any help that could be provided.
I figured it out. The fact that i could get into isql with the IP address made me think that maybe 0.0.0.0 is somehow not available to Bcp.
I modified c:\sybase\ini\sql.ini with the following:
from:
[Sybase157]
master=NLWNSCK,0.0.0.0,5000
query=NLWNSCK,0.0.0.0,5000
drd02=NLWNSCK,0.0.0.0,5000
to:
[Sybase157]
master=NLWNSCK,123.123.123.123,5000
query=NLWNSCK,0.0.0.0,5000
drd02=NLWNSCK,0.0.0.0,5000
after putting my public IP address of my vm in the sql.ini, bcp was able to speak to it correctly.
I should mention this was just a one-time fix to make it work, making this change will probably mess up external connections to the db. You'd need a loopback adapter or something to make this work right.
Related
While connecting to sybase, i'm trying to start my server using
startserver
but, i have encountered the above error.
The usual way to start a Sybase instance is:
startserver -f RUN_SERVER_FILENAME
e.g RUN_MY_INSTANCE or similar depending on what your Sybase instance is called. Once its started correctly then you should be able to connect. This is usually in the $SYBASE/$SYBASE_ASE/install directory on a default installation for Unix.
More info here:http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc30191.1570100/doc/html/san1367605056632.html
Are you getting any other messages? You should look at the instance errorlog to check for problems on startup.
I am in the process of setting up a remote PostgreSQL database. The server is running CentOS 7 and PostgreSQL-9.5. Currently, I am testing whether users can query the database. To this end, I have the following:
import psycopg2
host = 'server1'
dbname = 'test_db'
user = 'test-user'
sslcert = 'test-db.crt'
sslmode = 'verify-full'
sslkey = 'test-db.key'
dsn = 'host={0} dbname={1} user={2} sslcert={3} sslmode={4} sslkey={5}'.format(host, dbname, user, sslcert, sslmode, sslkey)
conn = psycopg2.connect(dsn)
The connection times out with the following error:
psycopg2.OperationalError: could not connect to server: Connection timed out (0x0000274C/10060)
Is the server running on host "server1" (xx.xx.xx.xx) and accepting
TCP/IP connections on port 5432?
I have tried several things (given below). I'm trying to pin down on which side the problem exists: the Python end or the database configuration:
Is the Python syntax correct?
Where can I find documentation concerning the DSN arguments, such as sslmode, sslcert, and sslkey?
Is there a different package better suited for this kind of connection?
What other questions should I be asking?
I have checked the following:
'server1' was entered correctly and the IP address returned by Python corresponds
All other arguments are spelled correctly and refer to the correct object
Postgres is currently running (service postgres-9.5 status shows "active")
Postgres is listening on port 5432 (netstat -na | grep tcp shows "LISTEN" on port 5432)
SSL is running for my table (psql -U username -W -d test-db -h host returns SSL connection (protocol: TLSAv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
user=test-user has been added to postgres as a Superuser
My understanding is that psycopg2 is the appropriate package to use nowadays. I have scoured the documentation and don't find much information regarding SSL connections. I found this SO post which talks about SSL connections using psycog2, but I can't match some of the syntax to the documentation.
In the Python script, I have tried the following in all 4 combinations:
Use sslmode='require'
Use absolute paths to test-db.crt and test-db.key
It appears that you have presented yourself with a False Dilemma. The problem does not lie solely between Python and the database configuration. There exist other entities in between which may cause a disconnect.
Is the Python syntax correct?
Yes. The syntax is described in the psycopg2.connect() documentation. It has the form:
psycopg2.connect(dsn=None, connection_factory=None, cursor_factory=None, async=False, **kwargs)
where the DSN (Data Source Name) can be given as a single string or as separate arguments:
conn = psycopg2.connect(dsn="dbname=test user=postgres password=secret")
conn = psycopg2.connect(dbname="test", user="postgres", password="secret")
Where can I find documentation concerning the DSN arguments, such as sslmode, sslcert, and sslkey?
Note that as DSN arguments, they are not part of the psycopg2 module. They are defined by the database, in this case Postgres. They can be found in the chapter on Database Connection Control Functions, under the Parameter Key Words section.
What other questions should I be asking?
Perhaps,
Is there anything between the host (the PostgresSQL server) and the client (the local Python instance) which could prevent communication?
One answer to this would be "the firewall." This turned out to be the problem. Postgres was listening and Python was reaching out. But the door was closed.
I'm trying to connect to an MS SQL database from R (on a Mac) - after fiddling a lot with odbc.ini, odbcinst.ini, and installing freeTDS as described:
sudo port install freetds +mssql +odbc +universal
it now works on the Mac's command line level, but when trying to access it from R using the command:
con <- odbcConnect("myDSN", uid = "myID", pwd = "myPWD")
it just hangs and when forced to stop executing, I get 50+ of the following warnings:
In odbcDriverConnect("DSN=myDSN;UID=myID;PWD=myPWD") :
[RODBC] ERROR: state IM002, code 1421220112, message [iODBC][Driver Manager]Data source
name not found and no default driver specified. Driver could not be loaded
After having tried to make it work for about two days, I'm running out of suggestions. Can anybody help point me to what I am missing?
EDIT: It also works when running R on the virtual Windows machine. How do I get it to work on the Mac?
Did you first configure your MS SQL driver connection? If you have, then you should have a data source called "myDSN" in the OCBC Data Source dialog box.
Here is a great blog which gives step-by-step instructions and screen captures for what you need to do.
When you issue queries in R, R will try to talk to the ODBC data source called "myDSN". That data source knows what database you want (MS SQL) and also what the credentials (username/password) are needed to get access. This is the reason why you must configure the data source.
I am using SQL Server 2008 R2.
I have created an SQL Job that fetches data from database tables and writes it to output file i.e. CSV on specific location.
For this I am using bcp and xp_cmdshell.
In bcp I need to pass the server name. Upto this I was using 'localhost' as server name, but by running this on another PC I have came to know that the 'localhost' login is not working on it so that the output files are not getting generated.
I searched about it and got another command that returns the server name along with server instance. i.e. SERVERPROPERTY('ServerName')
Now I am confused for using it. It is running OK with my local PC and Another PC also but my question is - Is it always run safely without any error if I put it on any other Server or PC? Which one of this is advisable to be used?
I think you're getting confused about the term "LocalHost". This is just an alias (aka loopback) that points back to the machine originating the connection.
For example, if my machine was named MYMACHINE and I was running a default instance on it, I could connect to the database either by specifying LocalHost or MYMACHINE and I would connect. If someone else was trying to connect from machine YOURMACHINE, they would only be able to connect to my database if they specified MYMACHINE. If they entered LOCALHOST it would try to connect to YOURMACHINE as that is where the connection is originating.
Back to your question now, yes, it is safe to get the servername value from SERVERPROPERTY('ServerName') as it will always report the correct and current network name of the server. This is not the case with ##SERVERNAME, so you should shy away from that for your purposes.
LocalHost: https://en.wikipedia.org/wiki/Localhost
##ServiceName (last paragraph of remarks section is important): http://msdn.microsoft.com/en-us/library/ms187944.aspx
P.S. I apologize for not adding a comment to the question, but my reputation is not currently high enough to do so.
I am locally running an Oracle 11g database. I have a small program connecting to it in code via OLEDB in VC++ (It only runs some database tests, I'm making sure I have all the basics down before I go into the real thing.) The connection information in code only includes the provider, instance name, user name, and password. All this aspect works fine.
//For example, both these ways of connecting work:
result = dataSource.Open(DATABASE_PROVIDER, DATABASE_NAME,
DATABASE_USER_NAME, DATABASE_USER_PASSWORD);
result = dataSource.OpenFromInitializationString(L"Provider=OraOLEDB.OracleDataSource=orcl;User ID=SYSTEM;Password=admin;");
I now want to send this program to other computers in my network and run it from there, connecting to my database on my local machine.
How would I go about connecting the other computers to my database in a way that the code will understand?
I have been trying to connect locally via IP instead of "localhost", figuring I could then simply use the same code and client. In that regard, I have tried a few things without success:
-I have tried modifying the connection string to change "Data Source" to my IP, but it could not connect.
-I have tried adding some parameters from other connection string examples I had seen, but they were not for Oracle and were ignored.
-I have also tried modifying tnsnames.ora and listener.ora to change local host to an IP address, but I know that didn't work, as it would still connect if I entered rubbish.
Anyone has the knowledge to help out?
For an Oracle db, you should set up a new tnsnames entry on their individual machines that points to your local db. Then use that new tns name as the datasource. You'll also need to make sure that your local db instance is accessible to them in the first place. (This is not enabled by default in Oracle Express, by the way.)
I've also generally had more success using msdaora as the data provider instead of OraOLEDB.