• Jaloopa (unregistered)

    The proper enterprise solution would be a stored procedure spGetDropdownValues. If it becomes necessary to have this configurable at a later date, it can be modified to take a table valued type parameter and the required values can be passed in

  • (nodebb)

    co-worker

    This word is spelled incorrectly, I think, in this case. It should be:

    cow-orker

  • WTFGuy (unregistered)

    About the only thing missing here is passing the string into SQL as a single field like "entry1,entry2,entry3" then using exceedingly clunky SQL-side string mangling to break it into separate records to be returned as a set. Complete with latent bugs if the input count ever changes or gets an unwanted space character or delimiter within it.

  • Industrial Automation Engineer (unregistered) in reply to Jaloopa

    Which would be a much better solution than what has been submitted. The full enterprise go-around may be top-heavy, but at least it is exensible in a systematic manner.

  • TheCPUWizard (unregistered)

    (Only took a quick glance, on a small screen), but could that not simple be LINQ with no DB involved???

  • Sole Purpose Of Visit (unregistered) in reply to WTFGuy

    Somewhere between latency and Heisenberg ... lies the bug.

  • (nodebb)

    The only complexity that these three literals ought to ever be involved with is translation into the users' languages.

  • (nodebb) in reply to Jaloopa

    You're thinking small here. The real enterprise solution would be a micro-service architecture with 4 APIs: one API for each option, and an orchestration API to request the individual options from the first 3 APIs. And each API gets its own database.

    Get on with the times, jeez.

  • Alex Zuroff (github) in reply to Mr. TA

    I think you're getting down to the pico-service level there...

  • radarbob (unregistered)

    probably didn't know how to concatenate strings in SQL; I had a cow-orker who did.... that fella concatenated each 1:M 1:M 1:M join result record into a single string along with the "target" report labels intermixed - yes, in the SQL. This exceeded the MS SQL single-record length limit so the third table join was dropped from the query. Somehow he convinced the customer there was nothing that could be done about it. Of course the state government department head could not tolerate 1/3 of the data missing so our customer manually created the missing part, thank goodness it was only once a month.

  • (nodebb)

    I wonder if this is really as stupid as it appears or whether it's compliance with a stupidly-written requirement to use the database for everything.

  • (nodebb) in reply to LorenPechtel

    :why-not-both:

  • Peter D (unregistered) in reply to LorenPechtel

    It IS as stupid as it appears. You're just asking for the root source of the stupidity.

  • (nodebb) in reply to LorenPechtel

    I don't think "put these values into the database" is necessarily a bad idea but I have a feeling it was misunderstood quite thoroughly!

Leave a comment on “Select Your Dropdown”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article