I want to figure out which DNS resolver was used when making connect call to debug if the issue of
"error code 6: resolution failed"
I tried to look up here: http://curl.haxx.se/libcurl/c/curl_easy_getinfo.html ,
but there is no hint of how to get this info?
I presume it uses getaddrinfo system call at its base layer.
No, you can't get that exact info from a run-time libcurl. You can use curl_version_info to figure out which resolver backend it uses and then read the FAQ on further details:
http://curl.haxx.se/docs/faq.html#How_does_libcurl_resolve_host_na
Related
I have a c++ application which uses occi for connecting with database. I am using occi connection pool mechanism. Recently I have got an error ORA-00257 and it looks like after that nothing is working.
Can you please advice how to handle ora-00257 using occi?
Did you even try to google ORA-00257?
First match:
"How to Fix ORA-00257: archiver error. Connect internal only, until freed. A very common Oracle database error that is basically telling you that you have run out of logical or physical space on the mount, disk, or your db_recovery_file_dest location that holds your archivelogs."
I am developing a C++ network application on Windows. I need to check if internet connection is there or not. I am using gethostbyname(), but it is giving incorrect information when the system is connected through a proxy. InternetCheckConnection() and InternetGetConnectedState() are also not giving reliable results under different conditions. Is there a reliable way to check for internet connectivity covering all the conditions such as proxy and VPN?
Update:
In our company network WinHttpGetProxyForUrl() is failing with the error ERROR_WINHTTP_AUTODETECTION_FAILED and WinHttpSendrequest() is failing with error ERROR_WINHTTP_NAME_NOT_RESOLVED.
In open network WinHttpSendrequest() is successful.
Plain old way !
Include:
#include <wininet.h>
#pragma comment(lib,"Wininet.lib")
In your Method:
char url[128];
strcat(url, "http://www.techtoolbox.com");
bool bConnect = InternetCheckConnection(url, FLAG_ICC_FORCE_CONNECTION, 0);
if (bConnect)
{
//internet connection exists !
}
else
{
//internet DOES NOT connection exists !
}
Hope it helps.
The best way to test the availability of any resource is to try to use it. You only care about the Internet if there is something out there you want to connect to. So, try to connect to it, in the normal course of your program, and handle the errors. Don't try to second-guess what might happen if you try. First, you're trying to predict the future. Second, you aren't necessarily exercising the same things that the actual connection would exercise. Third, your test may succeed and your subsequent use fail due to an intervening condition changing. Fourth, you have to handle the errors from the real use of the resource anyway: why write all that code twice?
A simple solution is to try to connect to a well-known host, if it succeeds then you have a connection.
In my opinion a way is to create a socket and try connecting a known host. These links will help:
For windows: http://msdn.microsoft.com/en-us/library/ms740673(VS.85).aspx and for unix http://www.tenouk.com/cnlinuxsockettutorials.html.
HTH
Anil
My C++ app needs to deal with SSCE database files belonging to different versions. Right now, I have no way of knowing the version of the database.
The problem is that if the version of the OLEDB SSCE provider mismatches the version of the database file, IDBInitialize::Initialize() fails with E_FAIL. One has to obtain the respesctive IErrorInfo object to get a meaningful error message.
The point is that the error code of E_FAIL does not tell me whether the failure is because of the version mismatch or for some other reason. In the first case, I should retry with another SSCE provider, while in the second the application should terminate.
How can I implement this logic? Is there some API that I can invoke before calling IDBInitialize::Initialize() to check the version compatibility? Is there a way to get the real error code instead of the opaque E_FAIL?
Thanks.
You can look at the first bytes of the file - see this sample in C# - http://erikej.blogspot.com/2010/08/how-to-upgrade-version-3x-database-file.html
from my C++ source, I am starting an RPC service calling svc_run(). Everything looks just fine and I can see my service running if I type rpcinfo -p in my terminal.
Now I am working on a "cleanup" function which should stop this service and remove it from the rpcinfo -p list.
How can I do that? At the moment I am only able to stop it using sudo rpcinfo -d program version in my terminal. How can I do this from my source file?
Thanks.
After some time, I found out how to do this. Actually I faced some unexpected difficulties. The standard way to do this would be to use this:
svc_unregister(PROGID, VERSION)
but somehow, it did not work for me. After lots of trial and some online help (http://www.spinics.net/lists/linux-nfs/msg05619.html) I was able to delete the RPC service calling:
pmap_unset(PROGID, VERSION);
Hope this will help :)
Try to use void svc_exit(void) function. For more detailed description please refer to rpc_svc_calls chapter.
I tried this force stop of svc_run(), however did not find a solution, I however made the svc_run() stop from within the registered function and then it stopped - perhaps this could help you - please look at this : svc_exit Subroutine
The 'nicest' solution is to use both DevCpp's and Danilo's solution combined:
Among the RPC functions of your server, define one function which, when called by the client, executes svc_exit(). This will let your RPC server return from the svc_run() loop. Now you can either extend your RPC client application or create a separate client application to terminate your server.
In your RPC server's main program, right after the call to svc_run(), execute 'pmap_unset(PROGID, VERSION);'. This will let rpcbind unregister your RPC address.
Then do the usual cleanup of your application.
This combination allows your RPC server to run as a demon, i.e. without user interaction, while still offering a clean exit without having to cancel the process.
when I use SQL*Plus, connecting to a user whose password entered the grace period (Oracle 11g, Oracle 8i), I get an error message but the connect is still successful:
SQL*Plus:
=====================================
SQL> connect gumiplesku
Enter password:
ERROR:
ORA-28002: the password will expire within 7 days
Connected.
SQL> select User from dual;
USER
======================================
gumiplesku
=====================================
On the other hand, in my C++ OCI code doing a OCILogon2, if I try to connect the same user, I get an OCI_ SUCCESS_ WITH_ INFO with the same "error", but if I continue, the OCISvcCtx* I got seems to be invalid (even though it's not null), since trying to do a OCIAttrGet or OCIStmtExecute on it gives me an OCI_INVALID_HANDLE error.
User should successfuly connect to database during all his grace period, until his password will be totally expired.
So how come SQL*Plus can connect OK, when I get a bad handle? Shall I be attempting to connect a different way?
Many thanks.
This is a little outside my experience, but since nobody is answering I'll give it a shot.
I recall there being some kind of error handler callback you can install. Since you are able to get the error information via OCIErrorGet (?), I assume it's triggering normal error handling mechanisms. Is it possible that there's an error handler that closes the connection when an "error" occurs without checking for this special case?
This also reminds me of a problem I had long ago, if you pass in the wrong handle type to OCI functions they can fail in odd ways. From a look at the OCIErrorGet docs, it might be that you're passing in OCI_HTYPE_ERROR and an environment handle, or OCI_HTYPE_ENV and an error handle.
Are you calling OCIErrorGet multiple times? Oracle can generate multiple errors, maybe you have to retrieve them all before continuing? But that doesn't really seem reasonable.
Beyond those long-shots, I would try a simple OCI example or any example code from Oracle to see if it has the same issue. If not, then work backwards to find what's making the difference.