Zip Code Proximity Search - The Guts
In the previous post, we had a Zip search gone awry. The reason why was WTF-ey in itself, but the guts of this monstrosity were truly a sight to behold. For the sake of brevity, I'll step you through the process.
- User's search criteria is fed to VBScript "logic".
- "Logic" determines which query to run. All queries happen to be identical.
- Query is run, data is returned - from MSAccess database.
- Data from recordset object is moved to XML object.
- Data is sorted by XML/XSL abomination (more VBS "logic" determines how).
- Sorted XML data (anywhere from 30K to >500K) is stored in Session variable - just in case, you know, they try the exact same search again during this session. Don't want to make any extra trips to the database!
- Sorted XML is moved back into recordset object (God only knows how or why - still trying to figure that one out)
- Recordset is displayed on page (via a multitude of VBS functions which contain presentation-level code).
"My eyes, the goggles..." doesn't really cut it for this one. I think I'm going to need therapy.
I think you may have spared our sanity by not showing us the actual code.
Have you sough counciling after reading that code yet?
Juuuuuuuuuuuuuuust for future reference, you are allowed to make this just-one-thread by replying to your own, original post (or editing it).
Design by MSDN tutorial.
I just finished re-writing that abomination with a single SQL query
-> pass a Zip Code and a maximum search radius to the stored proc, and
you get the locations back - in ascending order of distance from the epicenter. What a novel idea! I decided to leave out the XML business.