Are the posted questions getting worse?

  • Alvin - previous topic from a couple weeks ago, another reason to check out reportbuilder 3.0

    http://sqlcat.com/whitepapers/archive/2010/10/15/edgenet-realizes-the-power-of-dynamic-it-and-self-service-bi.aspx

    ---------------------------------------------------------
    How best to post your question[/url]
    How to post performance problems[/url]
    Tally Table:What it is and how it replaces a loop[/url]

    "stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."

  • Steve Jones - SSC Editor (10/25/2010)


    Some people are definitely not sure about how to research something, or unwilling to try. Or they want a quick solution without work.

    I'm definitely one of those who prefers a quick solution without work. Essentially I'm extremely lazy. That's why I work so hard to understand things and get my solutions thoroughly right - it makes life so much easier the next time the same problem crops up.

    Tom

  • CirquedeSQLeil (10/25/2010)


    Alvin Ramard (10/25/2010)


    CirquedeSQLeil (10/25/2010)


    Alvin Ramard (10/25/2010)


    Stefan Krzywicki (10/25/2010)


    Steve Jones - SSC Editor (10/25/2010)


    Some people are definitely not sure about how to research something, or unwilling to try. Or they want a quick solution without work.

    I would love a quick solution without work. Unfortunately, I've found the only way to get those is to do a lot of work the first few times.

    The old saying about give a man a fish ...... teach a man how to fish ..... just came to mind.

    Seriously?? Who has time to waste on fishing when I can get it much faster somewhere else? Who cares if the fish is on ice?

    I prefer to know how to get my own fish so I'm not stuck when the fish market is closed?

    If the market is closed, just steal it from a bear.

    That's what I call really doing it the hard way!

    Tom

  • Tom.Thomson (10/25/2010)


    I'm definitely one of those who prefers a quick solution without work. Essentially I'm extremely lazy.

    I think most good developers are to some degree.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

  • Ouch. Suddenly my Monday doesn't seem so bad.

    ---------------------------------------------------------
    How best to post your question[/url]
    How to post performance problems[/url]
    Tally Table:What it is and how it replaces a loop[/url]

    "stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."

  • Indeed, that's a tough one. I've dealt with those migrations. that is a case where you wish you had GUIDs

  • Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    As the Myth Busters would say:

    "Don't do this in production, EVER!!"



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

    For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]

  • Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    How about a system where users can go in and change their id whenever they want to whatever they want. with no change record.

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

  • Alvin Ramard (10/25/2010)


    Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    As the Myth Busters would say:

    "Don't do this in production, EVER!!"

    And don't forget the part that precedes that

    We are Professionals

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    Ah, the good old days. I worked for a dot com who's signature product was a port from Paradox. We had to maintain backward compatibility to it as well. What a hideous monster it was.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Grant Fritchey (10/25/2010)


    Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    Ah, the good old days. I worked for a dot com who's signature product was a port from Paradox. We had to maintain backward compatibility to it as well. What a hideous monster it was.

    Aw, I liked Paradox back in the early 90s. I wouldn't have wanted to maintain backwards compatibility with it though!

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

  • Stefan Krzywicki (10/25/2010)


    Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    How about a system where users can go in and change their id whenever they want to whatever they want. with no change record.

    Sounds like fun. Any FK's? If so then CASCADE UPDATES?

  • Grant Fritchey (10/25/2010)


    Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    Ah, the good old days. I worked for a dot com who's signature product was a port from Paradox. We had to maintain backward compatibility to it as well. What a hideous monster it was.

    Where I'm at right now the current system(s) are in FoxPro. It works. I'm part of the team re-writing the HR part using .NET and SQL Server, we redesigned. Making the data migration a bit more interesting, but long-term we'll be better off.

    Funny, because I've tried to talk them into moving the data, as is, into SQL Server and using the FoxPro front end. Just change to use ODBC/OLE DB to connect to the data. Couldn't get any buy-in.

  • Jack Corbett (10/25/2010)


    Stefan Krzywicki (10/25/2010)


    Jack Corbett (10/25/2010)


    So I got an email from a friend this morning asking for some SQL help. They are running a system that used to have multiple databases per location, but has been changed to use a single database with a location code. Vendor did the migration and now they have found that there are multiple people with the same ID (no PK's, unique indexes, or DRI). Now he needs to change the ID's for all the people in one location to remove duplicates. The only help he got from the vendor was a list of tables where the ID would have to be updated.

    I asked him for the product name so I could make sure no where I worked or made recommendations would buy it. Oh, and told him to tell the vendor they needed to bring an a SQL person to fix the database. This is a migration from FoxPro to SQL Server a few years ago, obviously with no redesign.

    How about a system where users can go in and change their id whenever they want to whatever they want. with no change record.

    Sounds like fun. Any FK's? If so then CASCADE UPDATES?

    If we were keeping the system I'd consider it, but we're moving to actual employee ids. Then the problem is historical information. There is absolutely no way to make those changes that is more valid than guessing. I'm looking more to a cutover date where we start to use the new ids and leave everything before as suspect.

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

Viewing 15 posts - 20,791 through 20,805 (of 66,712 total)

You must be logged in to reply to this topic. Login to reply