Comments by David A. Gray (Top 18 by date)

Reason for my vote of 5 \n This looks very intriguing, and it might enable us to become less dependent upon Platform/Invoke. Although P/Invoke doesn't bother me, per se, I know that it's fairly expensive.

Reason for my vote of 5 \n Thanks to you, today is a good day, because I learned something new. I am giving you 5 gold stars for bringing to my attention something that I hadn't given much serious thought. I learned something interesting, though perhaps totally useless (to me) today.

I don't see any obvious reference to a SQL query or stored procedure.

How are the row being inserted - custom application, Excel using SQL Servers as back end, or something else? Three hundred users is small potatoes. There must be a lot more to your story that you haven't told us, or have yet to discover for yourself.

At any rate, my first guess is that something is holding a connection open much longer than it should. If so, that suggests a serious design issue.

What's wrong with implementing it as a normal Web application? Install a Web server behind your firewall, and install the application into its web tree. The Web browser becomes your client, and you divide the work between client and server just as you would in any other Web application. The main difference is that, since it's behind your firewall, you can relax the security restrictions a bit.

Security best practices would have the firewall drop incoming packets on port 1443, unless the source IP address is on the local network. While there are legitimate cases for connecting over TCP/IP from outside, connections from the outside world can be made a lot more safe and secure by making HTTP requests or connecting to a Web service that talks to the SQL server.

How you "connect" to a flat file varies from platform to platform. Since you didn't identify the platform, we can only guess, and must of us are deficient in that skill. Maybe look under ISAM.

Equally important is that if the argument is a reference, you must pass by reference as well, using the address of operator (&).

The fact that setting it to zero causes all rows to be deleted makes it abundantly clear to me that rows are counted from 1. Eliminate the "-1" from bot of your limit definitions, and I'll bet that you get all rows.

My message was intended to be a comment in favor of the excellent solution that was already proposed. Only later did I notice that it was marked as another solution.

My reply was intended as a comment in favor of the excellent solution that was already posted; I didn't notice that it posted as another (redundant) solution.

You are correct. Nevertheless, the point is that 16 bytes is 128 bits, a trivial case that is unlikely to yield a collision, and sufficiently small that it is computationally practical to take a brute force approach.

To elaborate a bit, write a stored procedure that creates the new record from field values passed into it as arguments. The SP returns a single value, which is the key. You insert the value into the ID field when you post the form back, to notify the user that the record was saved.

The stored procedure is executed as a NonQuery, allowing you to capture its return value into a variable that receives it through the Execute NonQuery ADO method.

This is the approach I've used in several ASP.NET applications and at least a couple of desktop applications, all of which had SQL Server data bases behind them.