March 9, 2013 at 2:19 pm
Jeff Moden (3/8/2013)
Matt Miller (#4) (3/8/2013)
Jeff Moden (3/7/2013)
Revenant (3/4/2013)
Evil Kraig F (3/4/2013)
Revenant (3/4/2013)
I always find it frustrating when someone asks me or someone else to do things for which T-SQL was not meant, in this case parsing multilevel XML with multiple occurrences of the same tag, yet prohibits use of a tool that would make it a breeze - in this case XML LINQ via CLR Integration.Sorry Revenant. Don't mean to be the cause of your frustration in this case. Clean CLR isn't what scares my DBA's, it's letting my app coders loose with it.
It was not meant at you, Craig. I have been in that situation and I know how it feels.
I feel the same way... I just can't understand why anyone would actually use XML. 😉
Well I'd say XML would be like a lot of other items -it's a tool in the arsenal. Use it correctly and it can be VERY useful; use it badly or in the wrong context, and it blows up in your face.
Kind of like any other tool.
I strongly agree with the "right tool" sentiment. I just don't agree that XML is the right tool for the transmittal of data destined for a relational database. It seems like using a 100 ton crane to turn a monkey wrench especially when it's used to transmit otherwise flat data for a single database entity. Since I'm mostly a data troll, I've not read up on JSON but if it's a markup language that requires description tags for each row or each element, I'm not going to be very happy with that for data transmission, either.
It is, but the construction means that the same size of data fits in a file 2/3 the size of an XML file and it is directly queryable which makes it good for client-side apps.
--------------------------------------
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
March 10, 2013 at 3:36 am
Jeff Moden (3/8/2013)
...Since I'm mostly a data troll...
Does that mean you live under a bridge on Al Gore's information superhighway?
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
March 10, 2013 at 1:28 pm
Since it's the msdb job tables, it's a bit of a stretch to say we don't have data. That said, that had a feel of 'do this for me'.
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
March 10, 2013 at 1:32 pm
GilaMonster (3/10/2013)
Since it's the msdb job tables, it's a bit of a stretch to say we don't have data. That said, that had a feel of 'do this for me'.
Not a strech for me at all. I have no scheduled jobs on my computer here at home, so no data to work with. My development VM at work has no scheduled jobs, so again no data. The production systems are in theater (such as Afghanistan) on secure networks, so again, no data.
March 10, 2013 at 1:35 pm
GilaMonster (3/10/2013)
Since it's the msdb job tables, it's a bit of a stretch to say we don't have data. That said, that had a feel of 'do this for me'.
Plus, look how long he has been around here and at his sig block.
March 10, 2013 at 2:15 pm
Fine, you're right, I'm wrong, etc, etc.
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
March 10, 2013 at 3:12 pm
GilaMonster (3/10/2013)
Fine, you're right, I'm wrong, etc, etc.
Is there an echo in here?? How many times I have felt that way here. 🙂
No, you aren't wrong, just that I don't have any data to work with and I really don't feel compelled to make any in this case. More than willing to help, just give me something to work with is all I want.
March 10, 2013 at 3:24 pm
Lynn Pettis (3/10/2013)
GilaMonster (3/10/2013)
Since it's the msdb job tables, it's a bit of a stretch to say we don't have data. That said, that had a feel of 'do this for me'.Plus, look how long he has been around here and at his sig block.
I've participated in an exchange on these forums with this person. I don't recall the circumstances, but I do recall thinking that someone who expects strangers to help solve his/her problems for free probably shouldn't respond indignantly to a perfectly reasonable question and definitely shouldn't insult those strangers. I see that name on a post and just walk on by.
Jason Wolfkill
March 10, 2013 at 10:34 pm
Matt Miller (#4) (3/9/2013)
Jeff Moden (3/8/2013)
Matt Miller (#4) (3/8/2013)
Jeff Moden (3/7/2013)
Revenant (3/4/2013)
Evil Kraig F (3/4/2013)
Revenant (3/4/2013)
I always find it frustrating when someone asks me or someone else to do things for which T-SQL was not meant, in this case parsing multilevel XML with multiple occurrences of the same tag, yet prohibits use of a tool that would make it a breeze - in this case XML LINQ via CLR Integration.Sorry Revenant. Don't mean to be the cause of your frustration in this case. Clean CLR isn't what scares my DBA's, it's letting my app coders loose with it.
It was not meant at you, Craig. I have been in that situation and I know how it feels.
I feel the same way... I just can't understand why anyone would actually use XML. 😉
Well I'd say XML would be like a lot of other items -it's a tool in the arsenal. Use it correctly and it can be VERY useful; use it badly or in the wrong context, and it blows up in your face.
Kind of like any other tool.
I strongly agree with the "right tool" sentiment. I just don't agree that XML is the right tool for the transmittal of data destined for a relational database. It seems like using a 100 ton crane to turn a monkey wrench especially when it's used to transmit otherwise flat data for a single database entity. Since I'm mostly a data troll, I've not read up on JSON but if it's a markup language that requires description tags for each row or each element, I'm not going to be very happy with that for data transmission, either.
Well in our case it's more like we're moving the 100-ton crane, dissassembling it in transit and making a whole bunch of 1-ton tractors along the way:). The XML is very useful in that, because it allows us some sane way to maintain the relations while the data is in transit, and still have some control over data types etc.... Besides - we leverage an industry-specific interchange spec which was specified using XML, so it also opens us up to all sorts of pre-made tools to help us.
I get all of that especially when someone makes a "standard". Heh... EDI is another "standard" (which I also dislike only worse than XML) that does the type of thing you seem to be doing. With the understanding that I don't know what the actual complexities of what you've need to do actually are, there are some pretty simple ways to do some pretty complex things. XML certainly does what you want it to but it reminds me of buying a stick of gum and carrying it home in a full size shopping bag.
My take on it is that just because millions of people are using it, I don't have to think they're right. Unfortunately, because there are millions of people using it, I do have to put up with using it on occasion. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2013 at 10:40 pm
Stefan Krzywicki (3/9/2013)
Jeff Moden (3/8/2013)
Matt Miller (#4) (3/8/2013)
Jeff Moden (3/7/2013)
Revenant (3/4/2013)
Evil Kraig F (3/4/2013)
Revenant (3/4/2013)
I always find it frustrating when someone asks me or someone else to do things for which T-SQL was not meant, in this case parsing multilevel XML with multiple occurrences of the same tag, yet prohibits use of a tool that would make it a breeze - in this case XML LINQ via CLR Integration.Sorry Revenant. Don't mean to be the cause of your frustration in this case. Clean CLR isn't what scares my DBA's, it's letting my app coders loose with it.
It was not meant at you, Craig. I have been in that situation and I know how it feels.
I feel the same way... I just can't understand why anyone would actually use XML. 😉
Well I'd say XML would be like a lot of other items -it's a tool in the arsenal. Use it correctly and it can be VERY useful; use it badly or in the wrong context, and it blows up in your face.
Kind of like any other tool.
I strongly agree with the "right tool" sentiment. I just don't agree that XML is the right tool for the transmittal of data destined for a relational database. It seems like using a 100 ton crane to turn a monkey wrench especially when it's used to transmit otherwise flat data for a single database entity. Since I'm mostly a data troll, I've not read up on JSON but if it's a markup language that requires description tags for each row or each element, I'm not going to be very happy with that for data transmission, either.
It is, but the construction means that the same size of data fits in a file 2/3 the size of an XML file and it is directly queryable which makes it good for client-side apps.
Since you're able to directly query XML, as well, I'm not sure that's an advantage over XML. Based on what you said about JSON taking only 2/3rds the space of XML, I'll say they're headed in the right direction but it's still bloated compared to more conventional means.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2013 at 10:45 pm
dwain.c (3/10/2013)
Jeff Moden (3/8/2013)
...Since I'm mostly a data troll...Does that mean you live under a bridge on Al Gore's information superhighway?
Nah... I've gone wireless. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2013 at 11:11 pm
Lynn Pettis (3/10/2013)
GilaMonster (3/10/2013)
Since it's the msdb job tables, it's a bit of a stretch to say we don't have data. That said, that had a feel of 'do this for me'.Not a strech for me at all. I have no scheduled jobs on my computer here at home, so no data to work with. My development VM at work has no scheduled jobs, so again no data. The production systems are in theater (such as Afghanistan) on secure networks, so again, no data.
This is one case where the request for sample data is unnecessary imho. The request wasn't about any scheduled jobs in particular but more about figuring out how to navigate system objects in msdb. To create test data is easy enough if a "test" job doesn't already exist. Then again, I may be accustomed to doing that on a regular basis for a demo.
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
March 10, 2013 at 11:40 pm
SQLRNNR (3/10/2013)
Lynn Pettis (3/10/2013)
GilaMonster (3/10/2013)
Since it's the msdb job tables, it's a bit of a stretch to say we don't have data. That said, that had a feel of 'do this for me'.Not a strech for me at all. I have no scheduled jobs on my computer here at home, so no data to work with. My development VM at work has no scheduled jobs, so again no data. The production systems are in theater (such as Afghanistan) on secure networks, so again, no data.
This is one case where the request for sample data is unnecessary imho. The request wasn't about any scheduled jobs in particular but more about figuring out how to navigate system objects in msdb. To create test data is easy enough if a "test" job doesn't already exist. Then again, I may be accustomed to doing that on a regular basis for a demo.
Okay, I guess I am wrong this time. Unfortunately, I have no data to work with so I guess I should just walk away.
March 11, 2013 at 6:00 am
Lynn Pettis (3/10/2013)
SQLRNNR (3/10/2013)
Lynn Pettis (3/10/2013)
GilaMonster (3/10/2013)
Since it's the msdb job tables, it's a bit of a stretch to say we don't have data. That said, that had a feel of 'do this for me'.Not a strech for me at all. I have no scheduled jobs on my computer here at home, so no data to work with. My development VM at work has no scheduled jobs, so again no data. The production systems are in theater (such as Afghanistan) on secure networks, so again, no data.
This is one case where the request for sample data is unnecessary imho. The request wasn't about any scheduled jobs in particular but more about figuring out how to navigate system objects in msdb. To create test data is easy enough if a "test" job doesn't already exist. Then again, I may be accustomed to doing that on a regular basis for a demo.
Okay, I guess I am wrong this time. Unfortunately, I have no data to work with so I guess I should just walk away.
I thought about this some more. What's wrong with expecting someone who is asking for help with a query to post sample data (regardless of the source of the data), showing what the expected results of the query based on that data, and providing the code that isn't quite working right? We were provided the code, but what was the expected output (not just based on a word description) but being shown what was expected. I'm sorry, but I work much better when I see what is wanted. At work (no matter where I was working) I have always tried to get people to show me what they want, not just describe it.
Sample data, expected results, and the code they are working with; this has always been what we try to get from anyone asking for help. Why should it matter what table(s) are being queried?
Viewing 15 posts - 39,091 through 39,105 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply