Server-side processing rocks the house!
I’ve spent the last couple of weeks learning how to optimize the search tool we built. The short story is that we’re now using a pass-through query in Access to pass parameters to stored procedures on SQL Server. Processing time has gone from about 2 minutes to less than 2 seconds.
Now that I know how to work with stored procedures, I’m thinking of how else to implement them with other types of applications.
BACKGROUND
The company has clients spread across multiple databases for various reasons; namely specific business rules (e.g., worker’s comp rate, state tax rate, unemployment insurance, etc.) apply across an entire database.
Quite often someone in the company receives paperwork from an agency or client with nothing but the client employee’s name or their SSN. Searching for this employee has been trial and error, going through each database at a time. Also, in many cases the person in our company just needs to see some basic information about the employee. For example, during tax season we just needed to verify a client employee’s address and phone number. Hence the reason for such a tool.
We had initially designed the tool to have individual pass-through SELECT queries, uniting and applying criteria to them in Access. It was the uniting and applying criteria that has been slowing things down.
OPTIMIZING
So, I created two stored procedures with parameters: one that searches for an SSN one one that searches on a name. Each stored procedure unites the individual SELECT queries on a database separate from the other 12 that were being searched.
In VBA code, based on which criteria the user enters, we determine which stored procedure to run. We create a pass-through query to EXECUTE the stored procedure. This pass-through query then contains the search results, which is what we had with the earlier version of the tool.
PREVENTING SQL INJECTION
While reading the literature, I came across the concept of SQL injection and the need to prevent it. Since users are passing text to a SQL statment, we need to prevent the intentional or unintentional insertion of code that would prematurely terminate a text string and append a new command.
I wrote one procedure that scans what users enter in the first and last name fields for “–”, “CREATE”, and other such items. My coworker gave me some code to prevent users from entering other illegal characters. This double-barreled approach will prevent any SQL injection from occurring.
COMMUNICATING WITH THE MASSES
I enjoyed sharing the news of the updated tool with the rest of the company. I knew many had not even heard of it. I constructed the email the way I would a friendly blog post, including pictures.
One user immediately replied: “Awesome! Works very fast. Good job.” I was contacted by two people in Accounting and Payroll who asked that I put the tool on their machines as well.
Much joy all around, I tell you. And IT looks good.
—————-
Now playing: Tim Hawkins – KidsRock
via FoxyTunes
If you liked this post, click here to share it with your network!
Want to read more like this from Daniel Johnson, Jr.? If you do, subscribe right now!
Get via Email 
Add to Google 
Subscribe to the Feed
Tags: client relations, design, PEO, Search Tool, server-side processing, SQL, SQL Server
