We Keep Coding

Extremely slow mysql connection establishment only when called from code

I am currently trying to do something that should be simple and straight-forward - connect to a database server, run a query, see if I get anything back and if so send it back to the user. This is the code I'm using to do it:
MySqlDataReader reader = MySqlHeaper.ExecuteReader(connectionString, $"SELECT * FROM table WHERE insertDateTime > '{DateTime.Now.AddSeconds(-1800).ToString("yyyy-MM-ddTHH:mm:ss")}'";
I have also tried this with a MySqlCommand and MySqlConnection object pair, and either way the result is the same - it takes approximately 7100ms to connect to the MySql server. I know that sounds like a problem that should be on ServerFault, but my testing tells me otherwise. When I use the command line MySql client to connect to my database server using exactly the same credentials and run exactly the same query I get my connection established and my data back in nothing flat. I don't know at this stage if it's a server setting or not, but here's what I've tried so far:
Rebooting the server
Restarting the MySQL server
Setting the skip_name_resolve setting to 1 in order to prevent reverse name lookups on connect
Using alternative means of querying the server (mysql command line client and MySQL Workbench)
Opening all AWS IAM permissions on the RDS instance to allow everything from the server
Nothing seems to be making any difference, so I'm at a loss to explain this terrible performance. It's also only happening when I open the connection. Running queries, inserts, what have you is lightning fast. Any suggestions anyone might have would be most helpful.

I would not expect IAM permissions to have any impact on performance. I would expect them to be either successful or not successful.
I would execute some diagnostic protocols to get more information.
1) Try a subsequent query, to see if it is an issue with the stack being initialized. Are subsequent queries faster?
2) Try a query that is just an identity query. Something that doesn't require any sort of IO.
3) Try a query from a different platform (maybe a scripting language like ruby or php)
Once you answer those it should help you narrow it down.

This is most likely caused by Connector/NET executing a slow WMI query to query connection attributes when opening the connection; this is logged as MySQL bug 80030.
As far as I know, this isn't fixed in newer versions of the driver, but you can work around it by switching to MySqlConnector, an OSS MySQL ADO.NET library.

ODBC ISAM_EOF without any reason

I have a strange behavior with an ODBC Driver and the underlying COBOL database. The database driver is acuODBC of AcuCorp(now Microfocus), the database itself is a COBOL database.
The DSN is a system DSN and works just fine. Via Access/Excel u can read/write data with the DSN successfully.
In C# the ODBCConnection.ConnectionState is open. Retreiving the table headers works just fine. But when reading data, a strange error occurs. Here is a summerize of the trace log:
[Retreiving Column Headers]
ISAMRestrict - NO_ISAM_ERR
ISAMRewind - NO_ISAM_ERR
ISAMNextRecord – ISAM_EOF
This occurs when I add a WHERE clausel to the SELECT statement. When I do not add a WHERE clausel and just retreive the whole table, it takes incredible long (about 12 minutes for 40000 records), but at least I retreive data.
So my question would now be, has anyone else occured such a strange behavior with an ODBC driver? End of File where data should be?
Just as a side note, I have contacted Microfocus too, if they have a solution I will post it here.

It seems to be Windows UAC reliant. As our application run in compatibility mode, UAC visualization is active and causing may some problems. The reason for this is, that the COBOL databse is a file based database, and the client where are coding for uses these files in ODBC DSN config directly instead of running an ODBC server to handle the requests.
So the UAC leads to some strange behavior.

UserPrincipal.GetGroups crashing on only one server in the domain

I'm having issues with .NET's UserPrincipal.GetGroups() method.
On nearly all system in my domain I can call
var groups = UserPrincipal.Current.GetGroups().ToArray()
and it returns the groups the current user is in. But there is one Windows 2008 R2 Enterprise Server which crashes when executing this with the message:
The server is not operational.
Name: TESTDOMAIN.ORG
I think that this server has a different configuration somehow but it's part of the same domain.
Console.WriteLine(
new DirectoryEntry("LDAP://RootDSE")
.Properties["defaultNamingContext"]
.Value
.ToString()
);
Shows the same on all systems: DC=GLOBAL,DC=TESTDOMAIN,DC=ORG
Where could I look ? What could be the problem ? How to solve it ?

I finally found it.
The problem is, that the server did not know what standard gateway to use.
Solution is to go to network options, select the LAN interface which is used, edit the IPv4 entry and set a standard gateway. This way the network will no longer be shown as "unidentified network" under network neighbourhood and all LDAP related queries will work again.
This one struggled me for days, so I hope this answer could help you too.

How do I get MSMQ message count from a private queue on local Win7 machine?

I am trying to get a count of MSMQ messages from a private queue on a local Win7 Enterprise machine. I can get the count from a remote machine without problem and the code works on Win2008 Server R2. I am using C# VS 2008.
Code sample:
int result = MQMgmtGetInfo(cname, "queue=DIRECT=OS:" + qname, ref props);
where cname is the machine name with private queue, MyLocalComputer, and
qname is the path reference to the private queue, MyLocalComputer\\private$\\QueueName
When I call this code from the Win7 computer containing the private queue I get a -1072824319 return value. There are messages in the queue.
If I call this code from a WinXP computer to get counts on the Win7 queue, I get correct counts. I can also call the code from a WinXP computer to get counts from a local private queue on the same WinXP machine and get correct counts.
Is there something different about accessing local private queues on Win7? Since I can access the queue remotely I wouldn't think it is a permissions issue, but I may be wrong.

Sounds like you are using the MSMQ 3.0 API. Windows 7 uses MSMQ 4.0.
In the .NET references window look for System.Messaging (version 4.0.0.0) and add to your project.
Take a look in this link: http://www.codeproject.com/KB/cs/mgpmyqueue.aspx
[]'s
Renan

-1072824319 = 0xC00E0001 which is a generic MSMQ error.
Try using a full stop instead of the machine name.
That will tell MSMQ to use "local host".
If that works then there may be a problem with the machine resolving it's own name.
Cheers
John Breakwell

SQL Server: Could not find prepared statement with handle x

Recently our QA team reported a very interesting bug in one of our applications. Our application is a C# .Net 3.5 SP1 based application interacting with a SQL Server 2005 Express Edition database.
By design the application is developed to detect database offline scenarios and if so to wait until the database is online (by retrying to connect in a timely manner) and once online, reconnect and resume functionality.
What our QA team did was, while the application is retrieving a bulk of data from the database, stop the database server, wait for a while and restart the database. Once the database restarts the application reconnects to the database without any issues but it started to continuously report the exception "Could not find prepared statement with handle x" (x is some number).
Our application is using prepared statements and it is already designed to call the Prepare() method again on all the SqlCommand objects when the application reconnects to the database. For example,
At application startup,
SqlCommand _commandA = connection.CreateCommand();
_commandA.CommandText = #"SELECT COMPANYNAME FROM TBCOMPANY WHERE ID = #ID";
_commandA.CommandType = CommandType.Text;
SqlParameter _paramA = _commandA.CreateParameter();
_paramA.ParameterName = "#ID";
_paramA.SqlDbType = SqlDbType.Int;
_paramA.Direction = ParameterDirection.Input;
_paramA.Size = 0;
_commandA.Parameters.Add(_paramA);
_commandA.Prepare();
After that we use ExceuteReader() on this _commandA with different #ID parameter values in each cycle of the application.
Once the application detects the database going offline and coming back online, upon reconnect to the database the application only executes,
_commandA.Prepare();
Two more strange things we noticed.
1. The above situation on happens with CommandType.Text type commands in the code. Our application also uses the same exact logic to invoke stored procedures but we never get this issue with stored procedures.
2. Up to now we were unable to reproduce this issue no matter how many different ways we try it in the Debug mode in Visual Studio.
Thanks in advance..

I think with almost 3 days of asking the question and close to 20 views of the question and 1 answer, I have to conclude that this is not a scenario that we can handle in the way we have tried with SQL server.
The best way to mitigate this issue in your application is to re-create the SqlCommand object instance again once the application detects that the database is online.
We did the change in our application and our QA team is happy about this modification since it provided the best (or maybe the only) fix for the issue they reported.
A final thanks to everyone who viewed and answered the question.

The server caches the query plan when you call 'command.Prepare'. The error indicates that it cannot find this cached query plan when you invoke 'Prepare' again. Try creating a new 'SqlCommand' instance and invoking the query on it. I've experienced this exception before and it fixes itself when the server refreshes the cache. I doubt there is anything that can be done programmatically on the client side, to fix this.

This is not necessarily related exactly to your problem but I'm posting this as I have spent a couple of days trying to fix the same error message in my application. We have a Java application using a C3P0 connection pool, JTDS driver, connecting to a SQL Server database.
We had disabled statement caching in our the C3P0 connection pool, but had not done this on the driver level. Adding maxStatements=0 to our connection URL stopped the driver caching statements, and fixed the error.