March 17, 2017 at 1:36 pm
bmg002 - Friday, March 17, 2017 1:22 PMLynn Pettis - Friday, March 17, 2017 12:39 PMI 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.
March 17, 2017 at 1:42 pm
Lynn Pettis - Friday, March 17, 2017 1:35 PMbmg002 - Friday, March 17, 2017 1:22 PMLynn Pettis - Friday, March 17, 2017 12:39 PMI 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).
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
March 17, 2017 at 2:10 pm
bmg002 - Friday, March 17, 2017 1:42 PMLynn Pettis - Friday, March 17, 2017 1:35 PMbmg002 - Friday, March 17, 2017 1:22 PMLynn Pettis - Friday, March 17, 2017 12:39 PMI 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.
March 18, 2017 at 4:11 am
Lynn Pettis - Friday, March 17, 2017 12:39 PMI 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
March 18, 2017 at 8:21 am
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?
March 18, 2017 at 3:11 pm
Lynn - I'm good at dealing with XML in SQL too. Post the code and I'll also be happy to take a look.
-- Itzik Ben-Gan 2001
March 18, 2017 at 3:46 pm
Lynn Pettis - Friday, March 17, 2017 2:10 PMNot 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
Change is inevitable... Change for the better is not.
March 18, 2017 at 6:02 pm
Jeff Moden - Saturday, March 18, 2017 3:46 PMLynn Pettis - Friday, March 17, 2017 2:10 PMNot 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?
March 19, 2017 at 6:37 am
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
March 19, 2017 at 7:23 am
Matt Miller (#4) - Saturday, March 18, 2017 6:02 PMJeff Moden - Saturday, March 18, 2017 3:46 PMLynn Pettis - Friday, March 17, 2017 2:10 PMNot 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_405050723ugh.. 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
Change is inevitable... Change for the better is not.
March 19, 2017 at 1:19 pm
Jeff Moden - Sunday, March 19, 2017 7:23 AMDon'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?
March 19, 2017 at 3:59 pm
Matt Miller (#4) - Sunday, March 19, 2017 1:19 PMJeff Moden - Sunday, March 19, 2017 7:23 AMDon'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
Change is inevitable... Change for the better is not.
March 19, 2017 at 4:47 pm
Jeff Moden - Sunday, March 19, 2017 3:59 PMMatt Miller (#4) - Sunday, March 19, 2017 1:19 PMJeff Moden - Sunday, March 19, 2017 7:23 AMDon'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?
March 19, 2017 at 7:00 pm
Matt Miller (#4) - Sunday, March 19, 2017 4:47 PMJeff Moden - Sunday, March 19, 2017 3:59 PMMatt Miller (#4) - Sunday, March 19, 2017 1:19 PMJeff Moden - Sunday, March 19, 2017 7:23 AMDon'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
Change is inevitable... Change for the better is not.
March 19, 2017 at 7:55 pm
Lynn Pettis - Thursday, March 16, 2017 2:59 PMI 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 66,549 total)
You must be logged in to reply to this topic. Login to reply