From what I can tell, if make a bad query or I restart the server while a connection is open, in both cases PQresultStatus() will return PGRES_FATAL_ERROR (handling the result of PQexec). I'd rather know the difference because I'm working on a retry mechanism. Is that possible?
PQstatus() looks like it's the answer, and from my tests it seems like it is, but the documenation is a bit mealy-mouthed about its reliability.
I'm running PostgreSQL 9.4 on Debian 8.2.
Related
I am using a Solr server and store the data on a NFS volume. I know that this is not recommende, but in my case there is no other option. After encountering some locking-related error messages I tried out different locking settings. According to the solr documentation (https://solr.apache.org/guide/8_1/indexconfig-in-solrconfig.html) there are 4 lockTypes: native, simple, single and hdfs. But there is also the not really documented lockType none.
Since I also encountered issues with simple and single I am using "none", now and everything seems to be working fine. However, I am a bit worried now that at some point everything will crash and won't start again. Is this a possible scenario?
The Microsoft node.js sql server driver (https://github.com/Azure/node-sqlserver) has not had any commits for 11 months. Anyone know what's going on with this effort? My company is using it actively, but has run across some issues that led me to the repo and the discovery that it seems to have been abandoned. Lots of open bugs also.
Should we give up on this driver and try another? Any recommendations?
Microsoft, please weigh in here.
I emailed the Microsoft main contributor and he was very helpful, although he did admit that officially MS has never declared one way or the other if they were going to continue support. Guess we'll wait and see.
In regards to my original problem - this info may help someone.
I was using queryRaw and listening for events to build the response. This method allows the user to submit multiple sql queries in one request (just separate them with ;). A large text datatype field was getting truncated and I couldn't figure out why. Turns out that the 'more' parameter that is supplied by the driver means that you must concatinate the return data.
Lots of trial and error when figuring out this driver.
I am trying to use MongoDB on Ubuntu 11.10 with CakePHP 1.3 using the cakephp-mongodb driver from ichikaway, but I am seeing persistent connection problems.
My model is very simple. I am attempting a connect and a read
$this->loadModel('Mongo.Mpoint');
$data = $this->Mpoint->find('first');
However the result is inconsistent. A significant amount of the time the server returns
Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection
without sending any data.
However issuing a refresh, or several refreshes in quick succession will eventually deliver the expected returned data. It feels like the server is going to sleep and needs to be woken up as repeatedly hitting return does not generate errors, but this is subjective. The crash occurs in the find, not the connection itself.
I have rockmongo installed on the server which never fails to connect. Also I see the same behaviour if I point the connection at a different sever (same version of mongo, but on centos) so I do not believe the issue is with mongodb itself.
I have attempted setting the connection to persistent and directly setting the timeout, all without success.
My colleague, who also has a copy of the app running directly on the centos server, says he saw this problem initially, but 'it went away'.
From what I can see therefore the issue is most likely in the cakePHP layer as connections across different servers yields the same result and a direct connection in PHP is trouble-free, but placing diagnostics does not reveal anything of immediate use. It is rather odd to see a complete PHP crash with nothing useful returned from the server. Has anyone else seen this behaviour before and fixed it?
Try updating the Mongodb php driver. I had the same problem and I just upgraded from 1.2.7 to 1.2.9 and It seems to have been solved.
Just for reference
I am using
Ubuntu 11.10 x86
Xampp(Lampp) 1.7.7 with php-mongo-driver 1.2.9
Mongodb 2.0.2
CakePHP 2.0.6
cakephp-mongodb driver from ichikaway (Branch:cake2.0)
I guess Selenium isn't that important to this question but I thought I'd add it in. Also, I'm not using Rails.
I need to access Sqlserver and delete some records using ruby. Nothing too crazy. I've found some information online but I would like to know what you recommend is the best way to do this.
I've come across the DBI and SEQUEL gems but am unsure about the amount of time I'll need to invest to get up and running. Also, are there any better alternatives?
Thank you
You might want to try tiny_tds to see if that fits your needs. It's pretty bare-bones without an ORM.
I can capture the packets using wireshark, but I can't decode the stream into anything intelligible.
This item in the WireShark bug database suggests that maybe this isn't possible in SQL Server 2005 or newer. But several people on Stack Overflow claimed this was a good method in answers to this question:
How to validate SQL Server traffic is encrypted?
Any help appreciated.
Edit (2017-05-02): Microsoft Network Monitor - has been replaced by Microsoft Message Analyzer - which serves the same purpose. See also comment below this answer or the answer further down for how to use it!
Note: Microsoft Message Analyzer was deprecated in late 2019, and is no longer available for download.
Original Answer
There is another much underrated tool from Microsoft itself: 'Microsoft Network Monitor'. Basically this is very similar to wireshark with the exception that some specific MS protocols have better parser and visualisation support than wireshark itself and obviously it would only run under windows ;-).
The tool is quite old and looks abandoned (havn't seen a newer release so far) but still does an good job and the grammar for defining new protocols is quite neat/interesting - so this still possess a lot of power for the future.
Analysis Example - Recording is filtered for TDS - so the other packets are discared mostly:
This is also true for sql server connections. The MNM can even visualize the resultsets going over the wire - quite neat. Nonetheless wireshark as mentioned above would be sufficient to validate encryption and applied certificates on the wire itself. Means it can understand the TDS-Protocoll fully.
Handling TLS
Also with an extension (so called experts) 'NmDecrypt' and the right certificates (including private keys) - it is possible to decrypt protocolls - quite nice for TDS which uses TLS INSIDE of TDS - no wonder - no one has really implemented that yet as a fully supported protocoll for wireshark ;)
So far - regarding MSSQL-Traffic - or to be more precice TDS-Protocol this is the best tool I've come across so far. Wireshark is cool - but in this case MNM is 'better'. Have phun! ;)
Links for the tools:
Microsoft Network Monitor: http://www.microsoft.com/en-us/download/details.aspx?id=4865
NMDecrypt: http://nmdecrypt.codeplex.com/releases/view/85581
Not wireshark, but for me the Microsoft Message Analyzer worked great for that.
To get all the sent commands
Start a new session
Add Live Trace as as Data Source
Select Scenario (I chose Local Network Interfaces)
Enter a session filter expression like *address == 10.1.2.129 to filter only traffic to your sql server.
Click start
Right click on column header in the massage table and select Add columns...
Add TDS > SQLBatch > SqlBatchPacketData > SQLText
This should give you something like the following
Unfortunately there is no autoscroll implemented at the moment, but you can sort by timestamp and have the new queries popping up at the top.
The question that you are refering to is how to prove that the traffic is encrypted.
So they were using wireshark to show that you could not read it.
The encryption was weak on earlier versions of SQL server, but I don't think that it is easy to decrypt SQL Server 2005 traffic.
Wireshark decodes and shows you captured data when understand the protocol (and layer). That means the captured data isn't encripted.
If the data is encripted (SSL, ie), WS will only show SSL handshakes and raw data.