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.
Related
[
I install orcle database and oracle apex locally but
I am getting this error, when try to open the workspace
also the same schema when try to connect through the sql developer not connect and error show
How can I fix that?
To connect to the database, you make a request to a "listener" which then hands off your connection to the database. The listener listens (hence the name) on a port. If your listener is not running, or you are sending your request on the wrong port, then you see errors like this, because we can't find the listener.
Try this on a command line:
lsnrctl status
If you get errors, then your listener probably is not running. Go into Services, and you look for OracleTNS.... and start that. If your output suggests the listener is up and running already, then look for the information about the port and IP address (or hostname) that it is listening on. You then use those for your connection details in SQLDev and ORDS and the like.
I am running apache superset on docker, and I have been trying to connect to an external database(Postgres) using the example link on SQLAlchemy Docs for connecting to a Postgres database (postgresql://scott:tiger#localhost/mydatabase // postgresql://username:password#localhost:5433/postgres). However, I have been getting the following error: Connection failed, please check your connection settings. Could someone please help me with this.
Are you sure that your postgres is on the same network (localhost)? It seems for external database, that it would likely be on another network (and therefore you would use IP address)?
If these are the docs you are looking at --> https://docs.sqlalchemy.org/en/12/core/engines.html#database-urls
Then you might want to think in terms of 'host', meaning then an IP(v4) address and/or DNS.
As it was recommended you may need to whitelist your Superset IP address in pg_hba.conf.
You may also need to check if you have the right driver installed in the docker instance that you are running superset.
Please don't move this question to askubuntu as I think this question is not OS-specific.
When I invoke the createuser postgres command (for now it doesn't matter if I provide any parameters or not), I'm getting this error:
createuser: could not connect to database postgres: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Normally it means that the postgres server is down but not this time:
pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.4 main 5432 online postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log
sudo service postgresql status
9.4/main (port 5432): online
But it's true that there is no /tmp/.s.PGSQL.5432 file because my configuration file (/etc/postgresql/9.4/main/postgresql.conf) has this line:
unix_socket_directories = '/var/run/postgresql'
So I don't really understand why createuser whants to access /tmp/.s.PGSQL.5432? Can this path can be hardcoded into the createuser binary? I don't see any command line argument to specify the settings file location for createuser...
Have you started the service?
service postgresql start
The postgresql.conf file is read by the database server, but not by client applications (such as createuser, psql, ...). (In fact, the server configuration file cannot be read by client applications because the client would have to connect to the server, which could be halfway across the world, before it could possibly know where that configuration file lives).
Instead, you have to tell your client application where to find the socket directory.
If your client application (createuser) is connecting to the local host (which is must be because you are not specifying a different host), you use the host parameter to specify the name of the socket directory.
For example:
createuser -h /var/run/postgresql newusername
See http://www.postgresql.org/docs/devel/static/libpq-connect.html#LIBPQ-CONNECT-HOST
Hope that helps.
I have hosted my WebApp on server 1 and my database on server 2
But I'm getting following error
Communication with the underlying transaction manager has failed.
I googled and found a post which mentioned that it is the issue of DTC(Distributed Transaction)
I enabled DTC on server2(DB server) and made an exception of it in Firewall.
But still same error.
Here is the full stack trace
Message: System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)
at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32 propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier, Guid& transactionIdentifier, OletxTransactionIsolationLevel& isolationLevel, ITransactionShim& transactionShim)
at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
Kindly advice
We had the exact same situation, and more than once. Each time, it was one of the following:
The IP address in the DNS for the server is outdated (as said in error message: "two machines cannot find each other by their NetBIOS names"). You can check if this is the case by trying ping servername from one server to another in the command prompt. If the ping by name fails and ping by IP succeeds (or ping by name returns the wrong IP), than you should talk to the System Admins to take a look at DNS/DHCP.
The servers are created as an image of preconfigured server (for example, if you are working with virtual machines, and instead of doing a fresh install for each of the servers, you simply clone the image). This is a problem because DTC has an internal "Identifier" - and in case of image cloning both your installations now have same DTC ID, and won't be able to communicate with each other. The solution is to simply uninstall and install the DTC again.
Hope it helps.
Things to check:
Have you done this configuration on both servers?
Are both servers members of the same domain?
Have you checked the event log?
I had the same problem while connecting to a remote SQl Server.
The solution in my case was to add "enlist=false" to the connection string.
I was missing quite a lot of things:
No authentication (as DB server and APP server and not within same AD domain)
Rule to Windows Firewall enabling msdtc.exe
Rule to firewall between DMZ and internal zone TCP 135,1024-65535 in both directions. The link tell you how to restrict the firewall policy to few ports only.
short / long server names to hosts or a shared DNS server. Eg. 192.168.1.1 app1 as well as 192.168.1.1 app1.domain.local
On the other hand based on this link my setup doesn't require:
Allow Remote Clients
Allow Remote Administration
Enable XA Transactions (required prior Windows Server 2003 SP1)
Solved after adding remote IP\machine name to files on server:
hosts, lmhosts
in folder
C:\Windows\System32\drivers\etc
One of our servers displayed this error after the Virtual Machine (VM) controlling our Domain Controller froze. Several related communication problems also started to pop up (like failed password resets). Resetting the frozen VM fixed the issue.
Lots of helpful answers already given.
One problem for me was the presence of invalid (cyrillic) characters in the computer name.
And there is also a way to validate the connection between two servers (or between a server and a computer) using a small tool from Microsoft called DTCPing.
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.