Hi Golom,
Thanks for your input, as you say your solution seemed to me so OTT, that was part of why I couldn't wrap my head around it, it made no sense what it seemed to be doing for my situation, plus my T-SQL skills need improving!
I agree with you regarding hardcoded data types and perhaps if I was going to do that maybe I should have enumerated them?
Though you are only seeing half the picture as far as the usage and application goes, there are a bunch of forms with checkboxes on them, depending on the 'Rec_Type', 'Status' & 'Category' from the actual case record, and the app loads the appropriate form, for the case checker to then tick which documents were present on file at the time of check.
Now maybe I could refactor so there is a simple table with doc names, description (for the email that goes to the broker to request they complete the missing docs), and a counter (for the reporting), that could be used and then have one form that loads controls based on the docs table and then there would be no hard coding anywhere regarding the docs.
When you are given a specification on the back of a napkin and told they want a working version in 3 days, you have to compromise and take the shortest route, which sometimes involves hard coding.
Now I have a better grasp of the overall application and what they want from it, perhaps I might refactor, but as these regulatory required docs that haven't changed in 8 years and aren't likely to change in the forseable future, why add such dynamic ability and additional load on the SQL server for constantly looking up doc names and descriptions on every case accessed by the checkers (which are a lot), it seems over kill and an additional unwanted strain on our already overloaded VPN tunnel to constantly query SQL for something that can be hardcoded and left for the client machine to process not our SQL server nor our VPN tunnel thsat hooks up to SQL. If the list was likely to change regularly then a dynamic solution would be the only way to go, as it is unlikely to change year in year out, hardcoding seems the most efficient option. Well to me, would you agree?
Sometimes the right way isn't always the best way, when you weigh everything up.
Hey I know there is an argument that you should normalise your DB and never store multiple values in a single column anyway, and even that FAQ suggests using that method to refactor your DB and normalise it.
Though I see nothing wrong with CSV strings, especially as the most common usage in the app is to simply display the column on the history screen so you can see an audit trail easily of what docs were present on each check, as per the app specification.
The screen to display the data would use more resources (especially as it's via JET) if I had to link to another table to look up the 1-many records to get the existing docs (and there are several entries per case, as each time they chase the broker another entry is made in the history table), you could end up with 1 record linking to 100 records if the CSV string was normalised to another table, then having to join 3 tables together geting hundreds of records over JET, then having to concatenate them so the history form displays them as a CSV string on screen.
That to me seems well inefficient and so having a single CSV column in the history table, to me seems the better approach.
Perhaps I will be persuaded otherwise when I start my SQL course, but again due to the difference between T-SQL and JET, normalisation (especially 3rd normal form) can grind your Access app to a halt if done through standard Access queries & JET!
Perhaps I should try to refactor all queries to a T-SQL stored procedure or create more views?
But redesigning an entire DB and all applications that have been built around it over 10+ years, is a huge task, fraught with likely downtime and data corruption if not implemented correctly and as the IT department is just me, man power is also a premium!
Anyway enough of me wittering on, I got a report to finish ;-)
Though I must admit, the speed of my solution is so awesome, I'm not going to let a little hardcoding and a non-normalised table structure stop me from being chuffed!
As to your code, there are a couple of nit-picky issues ... which translates to "I wouldn't have done it that way"
As an aside, I am interested regarding what you would do differently and why, I'm always trying to improve what I do, (hence sending myself back to university), so I would appreciate your input.
"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."
"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Dance Music Downloads