Are the posted questions getting worse?

  • bmg002 - Friday, March 17, 2017 1:22 PM

    Lynn Pettis - Friday, March 17, 2017 12:39 PM

    I know it may be late in some locales, but is there anyone on that could help with some XML work?  I am try to move from OPENXML to using nodes on a project I am working on, even though I have a valid OPENXML solution.

    I am up as it is 1:00 PM here.  And I actually just had some fun doing the opposite.  I moved from nodes to OPENXML due to performance reasons.  But in my case, the nodes were pulling all of the XML, not parsing through small bits of it.
    Not really an XML or node/OPENXML expert by any means, and the stuff I was working with was VERY simple XML:
    <root>
    <parameter>
    <value></value>
    <value></value>
    <value></value>
    <value></value>
    <value></value>
    </parameter>
    </root>

    type stuff.  If yours is any more complex than that, I likely won't be very helpful.

    Nope, a bit more complicated with nested stuff to go into different tables.
    Thinking it may not be worth the hassles of changing direction now.

  • Lynn Pettis - Friday, March 17, 2017 1:35 PM

    bmg002 - Friday, March 17, 2017 1:22 PM

    Lynn Pettis - Friday, March 17, 2017 12:39 PM

    I know it may be late in some locales, but is there anyone on that could help with some XML work?  I am try to move from OPENXML to using nodes on a project I am working on, even though I have a valid OPENXML solution.

    I am up as it is 1:00 PM here.  And I actually just had some fun doing the opposite.  I moved from nodes to OPENXML due to performance reasons.  But in my case, the nodes were pulling all of the XML, not parsing through small bits of it.
    Not really an XML or node/OPENXML expert by any means, and the stuff I was working with was VERY simple XML:
    <root>
    <parameter>
    <value></value>
    <value></value>
    <value></value>
    <value></value>
    <value></value>
    </parameter>
    </root>

    type stuff.  If yours is any more complex than that, I likely won't be very helpful.

    Nope, a bit more complicated with nested stuff to go into different tables.
    Thinking it may not be worth the hassles of changing direction now.

    Yeah, I was expecting it to be more complicated.
    As for the reason to use nodes vs OPENXML, I THINK that nodes parse through XML to get a single parameter or value (using my above example) faster than OPENXML but OPENXML is faster to parse the whole XML chunk.
    I think nodes are also using a more standardize syntax.

    BUT I could easily be wrong.  XML is not my strong point (not even sure I have a strong point LOL).

  • bmg002 - Friday, March 17, 2017 1:42 PM

    Lynn Pettis - Friday, March 17, 2017 1:35 PM

    bmg002 - Friday, March 17, 2017 1:22 PM

    Lynn Pettis - Friday, March 17, 2017 12:39 PM

    I know it may be late in some locales, but is there anyone on that could help with some XML work?  I am try to move from OPENXML to using nodes on a project I am working on, even though I have a valid OPENXML solution.

    I am up as it is 1:00 PM here.  And I actually just had some fun doing the opposite.  I moved from nodes to OPENXML due to performance reasons.  But in my case, the nodes were pulling all of the XML, not parsing through small bits of it.
    Not really an XML or node/OPENXML expert by any means, and the stuff I was working with was VERY simple XML:
    <root>
    <parameter>
    <value></value>
    <value></value>
    <value></value>
    <value></value>
    <value></value>
    </parameter>
    </root>

    type stuff.  If yours is any more complex than that, I likely won't be very helpful.

    Nope, a bit more complicated with nested stuff to go into different tables.
    Thinking it may not be worth the hassles of changing direction now.

    Yeah, I was expecting it to be more complicated.
    As for the reason to use nodes vs OPENXML, I THINK that nodes parse through XML to get a single parameter or value (using my above example) faster than OPENXML but OPENXML is faster to parse the whole XML chunk.
    I think nodes are also using a more standardize syntax.

    BUT I could easily be wrong.  XML is not my strong point (not even sure I have a strong point LOL).

    Not mine either but looking like I need to learn it and JSON.

  • Lynn Pettis - Friday, March 17, 2017 12:39 PM

    I know it may be late in some locales, but is there anyone on that could help with some XML work?  I am try to move from OPENXML to using nodes on a project I am working on, even though I have a valid OPENXML solution.

    I do use XML-nodes almost daily, although I am not an expert.
    just post me some issues, I'll try to answer them.

    Louis

  • Lynn - If you need a hand with XML - post it and will take a gander at it.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Lynn - I'm good at dealing with XML in SQL too. Post the code and I'll also be happy to take a look.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001

  • Lynn Pettis - Friday, March 17, 2017 2:10 PM

    Not mine either but looking like I need to learn it and JSON.

    I found the following to be useful.  There are several lessons on XML here that even an old fart like me can understand.  Best of all, it explains that bloody "namespace" stuff better than any other place I've seen.  Turns out, you usually don't need it and the URL that you include has little meaning at all.
    https://mva.microsoft.com/en-US/training-courses/using-xml-in-sql-server-and-azure-sql-database-8747?l=lbHxuCk1_405050723

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Saturday, March 18, 2017 3:46 PM

    Lynn Pettis - Friday, March 17, 2017 2:10 PM

    Not mine either but looking like I need to learn it and JSON.

    I found the following to be useful.  There are several lessons on XML here that even an old fart like me can understand.  Best of all, it explains that bloody "namespace" stuff better than any other place I've seen.  Turns out, you usually don't need it and the URL that you include has little meaning at all.
    https://mva.microsoft.com/en-US/training-courses/using-xml-in-sql-server-and-azure-sql-database-8747?l=lbHxuCk1_405050723

    ugh.. now I have to go watch that 😀

    If that's the message they are conveying about XML schemata, then I'm actually worried about the rest of the content.   That's kind of like saying -"sure - you can use this new thing we call SEEEQUIL, but don't bother about using types or normalizing your tables.  Just put everything in a single table with VARCHAR(MAX)"

    Edit: wow.  I'd actually put that "typed XML" session  in the "could be dangerous" category.  It's a primer but it seems to want to cover too much material in too short a timeframe, so they are leaving out the "why" parts all over the place.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Anyone here who is a Chapter Leader or Volunteer for your local SQL User Group, I'm just taking over the South Florida SQL server User Group, and if you have any pointers  or tips , materials etc, I could use them! The previous leader, Diana Betancourt, took a new job with Microsoft, So I'm pitching in.
    We've got our local SQLSaturday #627 coming up,  so a bit of work and planning is coming up for our group!

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • Matt Miller (#4) - Saturday, March 18, 2017 6:02 PM

    Jeff Moden - Saturday, March 18, 2017 3:46 PM

    Lynn Pettis - Friday, March 17, 2017 2:10 PM

    Not mine either but looking like I need to learn it and JSON.

    I found the following to be useful.  There are several lessons on XML here that even an old fart like me can understand.  Best of all, it explains that bloody "namespace" stuff better than any other place I've seen.  Turns out, you usually don't need it and the URL that you include has little meaning at all.
    https://mva.microsoft.com/en-US/training-courses/using-xml-in-sql-server-and-azure-sql-database-8747?l=lbHxuCk1_405050723

    ugh.. now I have to go watch that 😀

    If that's the message they are conveying about XML schemata, then I'm actually worried about the rest of the content.   That's kind of like saying -"sure - you can use this new thing we call SEEEQUIL, but don't bother about using types or normalizing your tables.  Just put everything in a single table with VARCHAR(MAX)"

    Edit: wow.  I'd actually put that "typed XML" session  in the "could be dangerous" category.  It's a primer but it seems to want to cover too much material in too short a timeframe, so they are leaving out the "why" parts all over the place.

    Don't let the intro to the intro put you off too much (I have to admit, I almost gave up there, myself).  They get better as they get into it but, yes, they do some stuff that I'd never do and I'm no XML ninja.  My worry is what newbies to SQL Server may get out of it.  They seem to cover syntax and capabilities with no real world experience or coverage of caveats.  I think that's, with rare exceptions, the problem with most computer training and books, though.  There are so many holes you could go down on any subject within SQL Server that you could spend most of the time on the holes instead of the subject.  Like the old saying goes (from the Mayflower donut shops?) ....

    "As you ramble on through life, Brother,
    Whatever be your goal,
    Keep your eye upon the doughnut,
    And not upon the hole."

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Sunday, March 19, 2017 7:23 AM

    Don't let the intro to the intro put you off too much (I have to admit, I almost gave up there, myself).  They get better as they get into it but, yes, they do some stuff that I'd never do and I'm no XML ninja.  My worry is what newbies to SQL Server may get out of it.  They seem to cover syntax and capabilities with no real world experience or coverage of caveats.  I think that's, with rare exceptions, the problem with most computer training and books, though.  There are so many holes you could go down on any subject within SQL Server that you could spend most of the time on the holes instead of the subject.  Like the old saying goes (from the Mayflower donut shops?) ....

    "As you ramble on through life, Brother,
    Whatever be your goal,
    Keep your eye upon the doughnut,
    And not upon the hole."

    Oh I know:  I do get it.  Not using namespaces ranks somewhere between not qualifying your column names in queries and the (WITH NOLOCK) everywhere "best pactices" in my book, so it gets me a bit worked up :crazy:

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Matt Miller (#4) - Sunday, March 19, 2017 1:19 PM

    Jeff Moden - Sunday, March 19, 2017 7:23 AM

    Don't let the intro to the intro put you off too much (I have to admit, I almost gave up there, myself).  They get better as they get into it but, yes, they do some stuff that I'd never do and I'm no XML ninja.  My worry is what newbies to SQL Server may get out of it.  They seem to cover syntax and capabilities with no real world experience or coverage of caveats.  I think that's, with rare exceptions, the problem with most computer training and books, though.  There are so many holes you could go down on any subject within SQL Server that you could spend most of the time on the holes instead of the subject.  Like the old saying goes (from the Mayflower donut shops?) ....

    "As you ramble on through life, Brother,
    Whatever be your goal,
    Keep your eye upon the doughnut,
    And not upon the hole."

    Oh I know:  I do get it.  Not using namespaces ranks somewhere between not qualifying your column names in queries and the (WITH NOLOCK) everywhere "best pactices" in my book, so it gets me a bit worked up :crazy:

    I guess my question would be the same as if a query had only one table.  It you only have one "name-spaceable-thing", why would a name space be important?  And, no... not a challenge.  I'm trying to learn, as well.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Sunday, March 19, 2017 3:59 PM

    Matt Miller (#4) - Sunday, March 19, 2017 1:19 PM

    Jeff Moden - Sunday, March 19, 2017 7:23 AM

    Don't let the intro to the intro put you off too much (I have to admit, I almost gave up there, myself).  They get better as they get into it but, yes, they do some stuff that I'd never do and I'm no XML ninja.  My worry is what newbies to SQL Server may get out of it.  They seem to cover syntax and capabilities with no real world experience or coverage of caveats.  I think that's, with rare exceptions, the problem with most computer training and books, though.  There are so many holes you could go down on any subject within SQL Server that you could spend most of the time on the holes instead of the subject.  Like the old saying goes (from the Mayflower donut shops?) ....

    "As you ramble on through life, Brother,
    Whatever be your goal,
    Keep your eye upon the doughnut,
    And not upon the hole."

    Oh I know:  I do get it.  Not using namespaces ranks somewhere between not qualifying your column names in queries and the (WITH NOLOCK) everywhere "best pactices" in my book, so it gets me a bit worked up :crazy:

    I guess my question would be the same as if a query had only one table.  It you only have one "name-spaceable-thing", why would a name space be important?  And, no... not a challenge.  I'm trying to learn, as well.

    It's not AS important as when you have multiple but still valuable. 

    One of the original  assumptions around XML was that you could be interacting across a disconnected network, so frankly you can't assume what version of your code that remote agent might be configured to interact with. The URI format was really intended so that they *could* be valid, and orgs could publish their "contract" (how do you interact with them, what services they might offer).

    If you were to tag ALL messages when the NS they were based on (even if you don't tag every single element within the message), you'd know what version they are on so you'd know what to do with it.  One of the best practices there of course is that the URI contain not just the "what is it" but also what edition, usually in the form of a date.  Your validations can stay in play based on versioning, so you still get all of the goodness without the cost of a dedicated connection.

    We've built "up-sizing" code to fill in the blanks on older version of the messages so that they can fit into our newer editions, etc...

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Matt Miller (#4) - Sunday, March 19, 2017 4:47 PM

    Jeff Moden - Sunday, March 19, 2017 3:59 PM

    Matt Miller (#4) - Sunday, March 19, 2017 1:19 PM

    Jeff Moden - Sunday, March 19, 2017 7:23 AM

    Don't let the intro to the intro put you off too much (I have to admit, I almost gave up there, myself).  They get better as they get into it but, yes, they do some stuff that I'd never do and I'm no XML ninja.  My worry is what newbies to SQL Server may get out of it.  They seem to cover syntax and capabilities with no real world experience or coverage of caveats.  I think that's, with rare exceptions, the problem with most computer training and books, though.  There are so many holes you could go down on any subject within SQL Server that you could spend most of the time on the holes instead of the subject.  Like the old saying goes (from the Mayflower donut shops?) ....

    "As you ramble on through life, Brother,
    Whatever be your goal,
    Keep your eye upon the doughnut,
    And not upon the hole."

    Oh I know:  I do get it.  Not using namespaces ranks somewhere between not qualifying your column names in queries and the (WITH NOLOCK) everywhere "best pactices" in my book, so it gets me a bit worked up :crazy:

    I guess my question would be the same as if a query had only one table.  It you only have one "name-spaceable-thing", why would a name space be important?  And, no... not a challenge.  I'm trying to learn, as well.

    It's not AS important as when you have multiple but still valuable. 

    One of the original  assumptions around XML was that you could be interacting across a disconnected network, so frankly you can't assume what version of your code that remote agent might be configured to interact with. The URI format was really intended so that they *could* be valid, and orgs could publish their "contract" (how do you interact with them, what services they might offer).

    If you were to tag ALL messages when the NS they were based on (even if you don't tag every single element within the message), you'd know what version they are on so you'd know what to do with it.  One of the best practices there of course is that the URI contain not just the "what is it" but also what edition, usually in the form of a date.  Your validations can stay in play based on versioning, so you still get all of the goodness without the cost of a dedicated connection.

    We've built "up-sizing" code to fill in the blanks on older version of the messages so that they can fit into our newer editions, etc...

    Hmmmm.... are you saying that they don't need a local "XML" format file (style sheet?) if the URI has the location?  That would be interesting.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Lynn Pettis - Thursday, March 16, 2017 2:59 PM

    I know what I write isn't always grammatically correct here in the forums, but in more formal settings, like blog posts, articles, reports, etc. I find even simple grammatical errors an issue.  Does anyone else ever feel this way when reading these types of written communication?

    I don't worry much about grammatical rules because most of the rules that get people wound up are actually pure drivel, not rules at all.  Anything that's claimed to be a grammar rule that rules out some ordinary English usage that increases the languages capability of describing things accurately, concisely, and simply should clearly be treated as prescriptivist nonsense and given short shrift.  So split your infinitives if you feel like it when you have an advrb that qalifies them (be that adverb a single word or an adverbial phrase), strand your prepositions whenever appropriate, and offer a two finger gesture to anyone who waves some idiotic style manual that contradicts everything that competent experts in the structure or standard English thy to teach (most style manuals fall into that category) and remember to boldly go where those who shout "you can't say that" tell you not to.

    Tom

Viewing 15 posts - 57,826 through 57,840 (of 65,267 total)

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