- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Test data.
Admin
It also (strongly) suggests that id's aren't auto-generated, and are numbers converted to strings, probably starting out from '100000'.
Admin
this is to keep the print-out of said tables on one page. (which then can be put on a wooden table, photographed, emailed, and end its life-cycle bij a rule to trash any communications containing the magic numbers. all in all, a very reasonable workflow.
Admin
Those IDs might be special magic IDs created by some sort of testing procedure (yeah, I know, testing on Production), and therefore they must be ruthlessly hunted down and eliminated.
Admin
I can't decide whether I'm more offended by the use of magic numbers, the wrong data type for an integer, or the "sp_" prefix on the procedure names.
Admin
I was once working at a bank where the previous guy added lots of if-statements to the Stored Proc. The if-statements returned different columns/structure of the data. All if-statements compared a variable with a ISO 8601 date. The value for the variable itself was not passed in but set at the top of the SP with the current date/time. Basically it was his way of suppressing old code-paths without commenting them out or removing them completely and only being able to look them up in SVN (git was not a thing back then). But still be able to see when those different structures were returned. It was a right mess.
Admin
Why am I getting SCP vibes from this?
Admin
Could it be that we are only looking at a part of the primary key and that table1 and table2 are - in fact - some sort of "one true lookup table". The table might have a compound primary key consisting of two fields; ID and SUB_ID or something to store more generic things. The pseudo-numeric value for ID could come from some preprocessor value that gets translated to a number.
Something like ID = '109369' means customer-type. The table could be filled with values like: ID = '109369' SUB_ID = "regular" DESC = "Regular customer" ID = '109369' SUB_ID = "special" DESC = "Special customer" ID = '109369' SUB_ID = "on_hold" DESC = "Customer on hold" etc
For the record: I think this is horror. But I've seen it more than once.....
Admin
Where there are magic numbers, there must be a magic delete...?
Admin
INVEST. Stored procedures are not testable, therefore they don't exist :-)
Admin
varchar(6) primary key? Let’s hope this table doesn’t need room to grow The stored procedures smell like a way to grant constrained delete permissions to a user though. Why those two IDs remains anybody’s guess!!
Admin
Table names anonymised or are we really seeing table1 and table2 in the database? That hints at ... many more horrors.
Admin
Sure they are. With Visual Studio database projects, Azure support for spinning up a containerized database from a project in a few seconds, and the tSQLt testing library, database unit testing is now on par with where the rest of the world was in about 2003.
Admin
For testing you need reliable error propagation which means tracking for each statement dozens of error codes, so...
INVEST: Store procedures with proper error propagation for make them remotely testable are not small, therefore they don't exit :-)
Admin
I have a slightly more sane hypothesis than Steve The Cynic:
They're magic values, but this is a legitimate workflow. Some ancient import process creates them, something is done with them and this cleans them up to repeat the cycle.
Admin
Looks to me like someone's attempt to prevent a SQL injection attack. Probably associated, as another commentator suggested, with test procedures
Admin
Or it's a table where entries are never deleted and there is no way provided for users to delete them, not even for administrators. So years ago when some foul-up created two entries that had to be deleted, the programmer just wrote a little one-time use function to do it - and forgot to delete it afterwards.
Admin
That could be, but it seems bizarre to use an SP and not a script if these are test records. If these are primary keys, are they using an auto ident column? If so, why are they re-using the same keys the same way?
My guess is they are copying a database or table and using these SPs to prepare it to some state for some reason, but there must be a better way to do this.