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).
- Repeat!
"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.