views:

243

answers:

1

I'm attempting to help our network engineers troubleshoot a situation for one of our clients. This client purchased a point-of-sale system from quite literally a "mom-and-pop" vendor, and said vendor recommended SQL Server Express 2005 as the back-end database to save the client from having to incur extra licensing fees. (Please don't get me started on that!)

We didn't write the app, and because it's a commercial app, we have no source code available. (Not that it would help us if we did; the thing was built in PowerBuilder, so we don't have tooling for it.) The app does none of its own logging, that we can ascertain. All we have to go on is SQL Server Express's own logging.

In the application, an end user swipes a membership card. Occasionally (a few times a day), the swipe will not return data from the database. The message on screen will say, "Member 123 not found." (The member numbers are actually six digits, "000123.") A rescan immediately afterward returns the member data correctly.

We've eliminated the scanner itself as a source of issues -- it routinely scans the full six-digit number. A scan of SQL Server Express's log indicates that it is coming back online from being idle, often at the point of the scan (but also at several other times per day). (Idle mode is explained here.)

I understand that allocating/deallocating RAM the way SQL Express does is a time-consuming process, especially if we're talking about hundreds of megabytes at a time -- which appears to be the case.

What we're not sure of is whether or not we're getting back partial data, or if the app is simply failing to connect to the database and displaying a generic error message. Since everything is so opaque, and the client is (for obvious reasons) unwilling to pay us to sit in their facility for 8 hours or so to physically see it happen (perhaps with network monitoring/packet sniffing tools), we're kind of at a loss.

At this point, our recommendation is that the client upgrade to SQL Server 2005 Workgroup Edition, with 5 CALs. But that doesn't completely sit well with me as the solution to this issue, because I'm reasonably certain that no SQL Server ever returns partial data -- if you can't connect, you can't connect. (That said, I still recommend it because it's a solution to a number of their other issues!)

I don't have much experience with Express. (I never use it for anything but local development, and there only at home; I certainly never recommend it to my clients.)

My question to those who might have experience with Express is, have you ever seen an instance of SQL Express return partial data, without the app itself being the cause of it? Specifically, have you seen this behavior when returning from idle mode?

(For what it's worth, we're inclined to believe that the app is failing to connect and merely displaying a generic error message, lopping off leading zeroes on the member ID when it does. That seems the most reasonable answer -- a third question might be, do you guys concur with that assessment?)

+1  A: 

I've never heard of or experienced SQL Server Express returning partial data. It's essentially the same code base as the full SQL Server.

It is more likely that the application is experiencing a timeout (which defaults to 30 seconds) due to SQL Server Express going idle. The application probably receives a timeout that it does not expect and does not handle it well.

The problem and possible solutions are discussed in this forum thread: http://social.msdn.microsoft.com/forums/en-US/sqlexpress/thread/a8fbf8d6-9949-47a5-a32b-50f8131f1127/

I suspect you have a connection string that looks like this:

Data Source=.\SQLEXPRESS; Integrated Security=True;AttachDbFilename=|DataDirectory|\myDatabase.mdf;User Instance=True

From the referenced thread:

This connection string will cause an initial connection to the main instance (.\SQLEXPRESS) and then instruct the main instance to spawn a new instance of SQL Server under the user's context and attach the database specified to that new User Instance. The User Instance is a completely separate running instance of SQL Server form the main instance that is unique to the user and that will be shut down when there are no longer any connections to it.

This is totally different that attaching a database to the main instance, which stays running at all times, unless you've manually shut it down. If your question is about the main instance going into an Idle state, then your question is not unique to SQL Express and you should ask this question in the Database Engine forum. I believe all Editions of SQL Server have an Idle state and the other forum would be where you can find out how to affect that behavior.

Mitch Wheat
I'd given up on anyone ever even looking at this again. :) The client decided they didn't want to pay for us to fix it -- at least I presume so, as I've not heard back from them since troubleshooting. Nonetheless, we did discover user instances weren't enabled via the connection string.
John Rudy
Eventually, it looked like there really were no partial data returns -- the data being "returned" was the data which got sent, so it was most likely an app-level issue with a timeout. The app probably just displayed whatever we sent in the dialog box when it got any SQL Error.
John Rudy
I'm going to go ahead and accept this answer, "closing the loop" on this, so to speak. Technically, there IS no answer since this was a closed-source app issue. :) (And of course, we didn't write the app, so there was nothing we could do about it.)
John Rudy