Are the posted questions getting worse?

  • Ed Wagner - Wednesday, May 24, 2017 10:00 AM

    Eirikur Eiriksson - Tuesday, May 23, 2017 10:59 PM

    Ed Wagner - Tuesday, May 23, 2017 3:16 PM

    Eirikur Eiriksson - Tuesday, May 23, 2017 9:00 AM

    Neil Burton - Tuesday, May 23, 2017 7:16 AM

    Eirikur Eiriksson - Tuesday, May 23, 2017 7:12 AM

    jasona.work - Tuesday, May 23, 2017 6:30 AM

    So, for those in the US, any big plans for the upcoming long weekend?

    Me, I'm going to be painting our bathroom (oh fun,) and building some shelves for our cats to get up on to look out a window when they want.

    Weekend's task, breaking in the Pizza Oven
    😎
    Gardenline Pizza Oven

    Ooh shiny.  I want one of those but I've only got a small backyard (in the stone-flagged Northern England sense) and there's already a bike, charcoal grill and an offset smoker in there.

    Should not have posted this, now there is a queue of Italians outside my door asking when the pizzas will be ready😀
    😎

    What's the fuel source?  I ask because depending on what it is, you might be able to get some great heat out of it.  It makes for a better crust.

    It burns wood and charcoal, I'm going to try it out with oak. What would you suggest Ed?
    😎

    Oak and birch are good because they're hard and burn hot.  Just don't go with anything with a lot of resin - pine, spruce, etc.  Don't forget you can mix woods as well.  Personally, I like to use apple.  You'll find that experience will be your guide for what you and your family really like.  For example, I like smoke flavor a lot (too much, according to my wife 😛) and tend to use hickory and apple as my go-to for most things.  Don't be afraid to play around.  The real key for a pizza oven will be high heat.

    Thanks guys, will start simple and work from there 😉
    😎

  • Figured I post this here.

    One of my co-workers went out to PyCon this past week. For those of you who don't know, this is the big Python conference out west (USA). He was able to snag one of those really comprehensive salary research guides on the data professionals they polled recently. It was mostly polled on data scientist, but it did include some data engineers, data architects and so on.

    I don't know the complete statistics, but they kept it pretty straight forward in terms of who they talked too and how they sampled the data for the report. One of the interesting bits is that of the data scientist they polled, most were using MySQL as their main database tool. SQL Server was second, then Oracle and then Postgres. Then the top languages used was SQL, then Python, R, Java and so on.

    Off the bat, at least for people like me who work to support data scientist and other analytics, it's shows how valuable RDBMS and SQL still is to this area regardless of all the BIG DATA hype. Most of the people polled here are not only using SQL and other RDBMS, but also still responsible for doing their own SQL coding, ETL, cleaning and so on.

    To close, one thing to note here in terms of new technologies on the rise. Spark and Python had insane increases from last year. Spark for example may be a disruptor for some of these technologies that are still in heavy use.

    My interpretation of why RDBMS and SQL are still high is not because these data professionals are creating comprehensive data warehouses, but actually because of the ease of use. I would be willing to bet if they dived deeper into how they are used, they may find that MySQL is popular because it's free and most of these data scientist are using it only to store flat unrelational data similar to what some of the big data platforms are selling too. It's just it's likely easier on setup and data retrieval with RDBMS than say, Hadoop. If they need something much more than that, then things like Redshift and on-demand Hadoop with Spark is used for specific projects for greater processing power when needed.

    Cheers!

  • Brandie Tarvin - Thursday, May 25, 2017 6:37 AM

    jonathan.crawford - Thursday, May 25, 2017 6:27 AM

    cleaning up someone else's code is always fun. modifying something to work for all states instead of the one, and whoever wrote this one put (NOLOCK) after every local temp table they're accessing.

    don't want anyone else accidentally locking rows on your temp table, that's good thinking. Especially when you're populating a variable value within a loop using a SELECT, and not doing any data modification.

    Absolutely! Don't you know how much chaos that would cause?

    Obviously, you haven't read The Manual of Useless Coding lately. @=)

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    -------------------------------------------------------------------------------------------------------------------------------------
    Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses

  • jonathan.crawford - Thursday, May 25, 2017 7:22 AM

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    If this is in a Dev environment, switch the Database collation CS from CI and let them test their code on their own. @=)

    This tip brought to you from Evil DBA Overlords.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • Brandie Tarvin - Thursday, May 25, 2017 7:56 AM

    jonathan.crawford - Thursday, May 25, 2017 7:22 AM

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    If this is in a Dev environment, switch the Database collation CS from CI and let them test their code on their own. @=)

    This tip brought to you from Evil DBA Overlords.

    Oh, now that is a somewhat evil and twisted thing to do.  Love it. :hehe:

  • yeah, I'm on the dev side, so no. And no talking to my DBAs

    -------------------------------------------------------------------------------------------------------------------------------------
    Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses

  • Ed Wagner - Thursday, May 25, 2017 8:08 AM

    Brandie Tarvin - Thursday, May 25, 2017 7:56 AM

    jonathan.crawford - Thursday, May 25, 2017 7:22 AM

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    If this is in a Dev environment, switch the Database collation CS from CI and let them test their code on their own. @=)

    This tip brought to you from Evil DBA Overlords.

    Oh, now that is a somewhat evil and twisted thing to do.  Love it. :hehe:

    That is why I write all my code as if I was working in a case sensitive environment.

  • Every time I think I've come up with a way to cut the time required to migrate my databases to new servers, I find a new roadblock...

    /me thinks to self:
    Hey, I wonder if our mandated, I have no insight or control over, third party backup software could "fake" a log-shipping setup!  Have it restore a current full, then on a schedule restore the Transaction Log backups with no recovery until the customer is ready to pull the trigger!
    /me busily contacts the backup admin
    ***Time passes***
    Backup admin:  Yeah, no, the backup software can't be set up to restore the logs that way, I'd have to go in and continually update what it should be restoring from
    Me:  Dang it...
    /me thinks to self:
    Hey, I wonder if I *could* do log shipping and have the log shipping backup job take copy_only log backups!  I'll set up a test-case on my home sandbox this weekend and see!
    /me does some Googleing as well on the topic
    Hey, an article on SpaghettiDBAs blog on this EXACT topic!
    /me reads article
    Crud.  Nope doesn't work that way and there's no apparent purpose to a copy_only log backup to boot...

    Now, for those of you wondering why our hero isn't taking backups to disk and having the third-party backup software snag those?
    Disk space.  Well, more correctly, our servers are "hosted" by another group and if they were any stingier with disk space then every time one of my customers databases needed to grow I'd have to put in a ticket to get the disk expanded so the database could grow.  They wanted to allocate only 40GB(!!!!) for our new servers for the OS drive (Server 2012R2,) bear in mind, JUST the Windows directory on one of my servers is ~23GB (and that's not including the \Users directory or any of the stuff that gets put in \Program Files by the OS,) plus all the software *they're* mandated to install before I can get the server, plus the fact that Windows updates get downloaded to the C:\ drive, plus the fact that Windows updates keep copies of the files pre-update on the C:\ drive...
    So yeah, getting enough disk space out of them to keep a week or two of SQL backups (2 full a week, Diffs every weekday, TLogs many times a day) would be like trying to pull teeth from a non-sedated, very angry tiger by hand...

    Ah well, long weekend coming up, I'll probably play with setting up log shipping anyways...

  • jonathan.crawford - Thursday, May 25, 2017 8:19 AM

    yeah, I'm on the dev side, so no. And no talking to my DBAs

    Well, not any more, right? 😉

  • Brandie Tarvin - Thursday, May 25, 2017 7:56 AM

    jonathan.crawford - Thursday, May 25, 2017 7:22 AM

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    If this is in a Dev environment, switch the Database collation CS from CI and let them test their code on their own. @=)

    This tip brought to you from Evil DBA Overlords.

    Actually I might suggest this to our DBAs after seeing some of the code out there.

  • JustMarie - Thursday, May 25, 2017 10:45 AM

    Brandie Tarvin - Thursday, May 25, 2017 7:56 AM

    jonathan.crawford - Thursday, May 25, 2017 7:22 AM

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    If this is in a Dev environment, switch the Database collation CS from CI and let them test their code on their own. @=)

    This tip brought to you from Evil DBA Overlords.

    Actually I might suggest this to our DBAs after seeing some of the code out there.

    If you manage to get them to do this, please let me know the outcome. I'm feeling rather devilish right now and would love to hear the screams of developers thrown in one of Dante's nine circles of Heck.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • Lynn Pettis - Thursday, May 25, 2017 8:23 AM

    Ed Wagner - Thursday, May 25, 2017 8:08 AM

    Brandie Tarvin - Thursday, May 25, 2017 7:56 AM

    jonathan.crawford - Thursday, May 25, 2017 7:22 AM

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    If this is in a Dev environment, switch the Database collation CS from CI and let them test their code on their own. @=)

    This tip brought to you from Evil DBA Overlords.

    Oh, now that is a somewhat evil and twisted thing to do.  Love it. :hehe:

    That is why I write all my code as if I was working in a case sensitive environment.

    I do too.  I'm not in a case-sensitive environment, but I code like I am.  I think it's safer.

  • xsevensinzx - Thursday, May 25, 2017 6:59 AM

    Figured I post this here.

    One of my co-workers went out to PyCon this past week. For those of you who don't know, this is the big Python conference out west (USA). He was able to snag one of those really comprehensive salary research guides on the data professionals they polled recently. It was mostly polled on data scientist, but it did include some data engineers, data architects and so on.

    I don't know the complete statistics, but they kept it pretty straight forward in terms of who they talked too and how they sampled the data for the report. One of the interesting bits is that of the data scientist they polled, most were using MySQL as their main database tool. SQL Server was second, then Oracle and then Postgres. Then the top languages used was SQL, then Python, R, Java and so on.

    Off the bat, at least for people like me who work to support data scientist and other analytics, it's shows how valuable RDBMS and SQL still is to this area regardless of all the BIG DATA hype. Most of the people polled here are not only using SQL and other RDBMS, but also still responsible for doing their own SQL coding, ETL, cleaning and so on.

    To close, one thing to note here in terms of new technologies on the rise. Spark and Python had insane increases from last year. Spark for example may be a disruptor for some of these technologies that are still in heavy use.

    Spark's on my list of things to learn, right after Python, Azure (not the whole thing), and R.

    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
  • Ed Wagner - Thursday, May 25, 2017 11:46 AM

    Lynn Pettis - Thursday, May 25, 2017 8:23 AM

    Ed Wagner - Thursday, May 25, 2017 8:08 AM

    Brandie Tarvin - Thursday, May 25, 2017 7:56 AM

    jonathan.crawford - Thursday, May 25, 2017 7:22 AM

    they also keep switching case on their variable names, it's driving me nuts. @variable1 vs @VARIABLE1 vs @Variable1, all the same.

    If this is in a Dev environment, switch the Database collation CS from CI and let them test their code on their own. @=)

    This tip brought to you from Evil DBA Overlords.

    Oh, now that is a somewhat evil and twisted thing to do.  Love it. :hehe:

    That is why I write all my code as if I was working in a case sensitive environment.

    I do too.  I'm not in a case-sensitive environment, but I code like I am.  I think it's safer.

    I have the worst of both worlds. Most of our systems are case insensitive but our new ERP is case sensitive.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Considering that SSIS tasks are sometimes case sensitive and SAP software definitely is, it's just as well to get in the habit of treating everything as case sensitive instead of case insensitive. Though sometimes I forgot when I'm in a hurry.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

Viewing 15 posts - 58,711 through 58,725 (of 66,000 total)

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