March 16, 2016 at 12:42 pm
Ed Wagner (3/16/2016)
jasona.work (3/16/2016)
Shoot me, please, just shoot me...So, several (most) of my servers have silly-small C:\ drives for the OS. This hasn't been a problem until recently, now those drives are getting nearly full (mostly from the various and sundry crap applying OS updates leaves behind.) In the past, I was able to work around this by moving things like the swap file for the OS to other drives, but now that's been done in the past and I've got nothing (easy) left to try...
I could request increasing the size of the drive (love me VMs,) but we're working on getting new servers (also VMs) with bigger C:\ drives to migrate to, so I'm not sure if it'll be worth the hassle of running that through the process...
It's only one VM at the moment really complaining, so I'm trying one other trick to clean up the old update files, but that's taking long enough (thankfully it's a QA VM) that I'm seriously thinking about just rolling back on my snapshot and saying "da heck wit' it."
Sigh...
At least I wasn't the one who originally requested the VM...
And at least it's not production VMs having this problem (right now.)
OK, ranting over, we now return you to your regularly scheduled madness and mayhem.
Knowing who you work for, getting new hardware could take a while. The bureaucracy could involve...well...never mind. Get the paperwork done so at least it's initiated for when you don't get your new hardware on time.
I'm reminded of someone's signature line - "A pessimist is an optimist with experience."
Yeah, it can. Another issue is, some of the VMs I've got were deployed with an image of the OS / drive. Normally not a problem, but this particular image has a "special" partition on the END of the drive rather than the beginning, which makes it an "adventure" for the VM team to extend the drive...
And, at least I am working with VMs, our Oracle DBA has to use physical servers, so an OS migration is a case of "OK, we'll take these two servers, use them for the migration, then take the original servers to migrate that Oracle, then take the two servers we're left with for something else."
March 16, 2016 at 3:38 pm
Solomon Rutzky (3/16/2016)
Jeff Moden (3/15/2016)
jasona.work (3/15/2016)
Reading the SQL2016 release notes, and especially Jeffs' comments here[/url], I'm wondering if maybe MS didn't bother to set up their string splitter with the capability of numbering the output because they expect people to fudge around that.Perhaps setting up a temp table with an identity column and inserting the split data into that, then working from there. A kludge, but a workable kludge...
Not sure how badly this would affect performance of any procedures that use it, though...
There's no way to guarantee the order especially since we don't know how it works behind the scenes nor if it's single threaded. With that, there is no workable kludge that will be supported never mind guaranteed.
Given the nature of the operation, it is most likely to be serial / sequential. Attempting to break up the input string in order to process it in parallel would require pre-parsing to find the delimiters so as to not break up a value into two pieces. And at that point you have already done half the work so why bother with parallel processing?
If using NVARCHAR data, breaking up a value could result in invalid UTF-16 byte sequences if the break happens to split a Supplementary Character. Similarly, if using VARCHAR data with one of the 3 supported Double Byte Character Set code pages, breaking up a value could result in invalid DBCS byte sequences. It might be possible to break up the string and not need to worry about invalid byte sequences IF the position of each set is maintained and stitched back together in the original order before releasing any values. But in that case the original order is still maintained.
Hence, it seems reasonable to expect the following to be reliable:
;WITH split AS(
SELECT vals.value, ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS [ItemNum]
FROM STRING_SPLIT(@InputString, ',') vals
)
SELECT *
FROM split;
However, this is just an educated guess, and proper testing (which I am not able to do at the moment) would be a better indicator than any speculation.
True enough but get Microsoft to post the guarantee of correct order in BOL. They won't do it. I've been down that road with Connor Cunningham on more than one occasion.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2016 at 4:11 pm
Well, I've spent all day, and a good portion of yesterday, in VSTS and TFVC online, trying to get database code to automatically build and release.
Good news, it's building.
Bad news, it's not releasing because of a) a bug, or b) my ignorance.
Don't place bets.
March 16, 2016 at 4:14 pm
Solomon Rutzky (3/16/2016)
Jeff Moden (3/15/2016)
There's no way to guarantee the order especially since we don't know how it works behind the scenes nor if it's single threaded. With that, there is no workable kludge that will be supported never mind guaranteed.Given the nature of the operation, it is most likely to be serial / sequential. Attempting to break up the input string in order to process it in parallel would require pre-parsing to find the delimiters so as to not break up a value into two pieces. And at that point you have already done half the work so why bother with parallel processing?
If using NVARCHAR data, breaking up a value could result in invalid UTF-16 byte sequences if the break happens to split a Supplementary Character. Similarly, if using VARCHAR data with one of the 3 supported Double Byte Character Set code pages, breaking up a value could result in invalid DBCS byte sequences. It might be possible to break up the string and not need to worry about invalid byte sequences IF the position of each set is maintained and stitched back together in the original order before releasing any values. But in that case the original order is still maintained.
Hence, it seems reasonable to expect the following to be reliable:
;WITH split AS(
SELECT vals.value, ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS [ItemNum]
FROM STRING_SPLIT(@InputString, ',') vals
)
SELECT *
FROM split;
However, this is just an educated guess, and proper testing (which I am not able to do at the moment) would be a better indicator than any speculation.
You might expect it, but it's not guaranteed, and no amount of testing ought to give you confidence in it. MS will not offer a guarantet that your "guess" will be correct, or even tht it is always correct with todatys implemenataion. Even if it were safe today, tomorrow MS may do something that overall provides a performance improvement or fixes a security problem or just makes MS feel happier about their product and that change may result in different behaviour. To me that means that in the medium or long term, as opposed to looking at the extreme short term involving only todays implemenatrion and hot-fix state, it's an uenducated guess not even an educated one.
Tom
March 16, 2016 at 8:14 pm
Jeff Moden (3/16/2016)
Solomon Rutzky (3/16/2016)
Given the nature of the operation, it is most likely to be serial / sequential...True enough but get Microsoft to post the guarantee of correct order in BOL. They won't do it. I've been down that road with Connor Cunningham on more than one occasion.
and:
TomThomson (3/16/2016)
You might expect it, but it's not guaranteed, and no amount of testing ought to give you confidence in it. MS will not offer a guarantee that your "guess" will be correct, or even that it is always correct with today's implementation. Even if it were safe today, tomorrow MS may do something that overall provides a performance improvement or fixes a security problem or just makes MS feel happier about their product and that change may result in different behavior. To me that means that in the medium or long term, as opposed to looking at the extreme short term involving only today's implementation and hot-fix state, it's an uneducated guess not even an educated one.
Ok, so I am understanding that you both are saying that without a stated guarantee of correctly ordered output (one which we aren't going to get) that even if the code does work this way, there is no way to have any amount of confidence in solutions using this function (where the ordering is important) because there could be edge cases that are difficult to test for (or at least impossible to know about), or undocumented changes that could alter the behavior.
Fair enough. I guess we do need a guarantee of some sort, either in writing (not gonna happen) or via an ItemNumber column. But for the record, I was never arguing against the desire to have this suggestion implemented. I guess I didn't state that here, but I did say in that Connect suggestion that I agreed with the suggestion (and voted for it) and was proposing a short-term work-around. Though I suppose now that without a stated guarantee, that it can't be ruled out that there is at least one edge-case that violates this expectation, such that my proposal really isn't a workable work-around, even in the short-term. In which case I would now agree that this function is probably too risky to use in cases where there is a functional dependency on the ordering.
SQL# — https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
Sql Quantum Lift — https://SqlQuantumLift.com/ ( company )
Sql Quantum Leap — https://SqlQuantumLeap.com/ ( blog )
Info sites — Collations • Module Signing • SQLCLR
March 17, 2016 at 2:03 am
jasona.work (3/16/2016)
Shoot me, please, just shoot me...So, several (most) of my servers have silly-small C:\ drives for the OS. This hasn't been a problem until recently, now those drives are getting nearly full (mostly from the various and sundry crap applying OS updates leaves behind.) In the past, I was able to work around this by moving things like the swap file for the OS to other drives, but now that's been done in the past and I've got nothing (easy) left to try...
I could request increasing the size of the drive (love me VMs,) but we're working on getting new servers (also VMs) with bigger C:\ drives to migrate to, so I'm not sure if it'll be worth the hassle of running that through the process...
It's only one VM at the moment really complaining, so I'm trying one other trick to clean up the old update files, but that's taking long enough (thankfully it's a QA VM) that I'm seriously thinking about just rolling back on my snapshot and saying "da heck wit' it."
Sigh...
At least I wasn't the one who originally requested the VM...
And at least it's not production VMs having this problem (right now.)
OK, ranting over, we now return you to your regularly scheduled madness and mayhem.
I had the same issue in the past, both with VMs and my laptop, where I partitioned the disk a bit too aggressively...
What I ended up doing is moving all the updates (C:\windows\Installer) to a second drive and creating a symbolic link from c:\windows\installer to d:\windows\installer
-- Gianluca Sartori
March 20, 2016 at 8:16 am
March 20, 2016 at 9:37 am
spaghettidba (3/17/2016)
I had the same issue in the past, both with VMs and my laptop, where I partitioned the disk a bit too aggressively...What I ended up doing is moving all the updates (C:\windows\Installer) to a second drive and creating a symbolic link from c:\windows\installer to d:\windows\installer
Oooooo.... you've got to tell me how to create that "symbolic link", Gianluca. That would solve a wealth of sins where I work.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2016 at 9:40 am
Solomon Rutzky (3/16/2016)
Jeff Moden (3/16/2016)
Solomon Rutzky (3/16/2016)
Given the nature of the operation, it is most likely to be serial / sequential...True enough but get Microsoft to post the guarantee of correct order in BOL. They won't do it. I've been down that road with Connor Cunningham on more than one occasion.
and:
TomThomson (3/16/2016)
You might expect it, but it's not guaranteed, and no amount of testing ought to give you confidence in it. MS will not offer a guarantee that your "guess" will be correct, or even that it is always correct with today's implementation. Even if it were safe today, tomorrow MS may do something that overall provides a performance improvement or fixes a security problem or just makes MS feel happier about their product and that change may result in different behavior. To me that means that in the medium or long term, as opposed to looking at the extreme short term involving only today's implementation and hot-fix state, it's an uneducated guess not even an educated one.Ok, so I am understanding that you both are saying that without a stated guarantee of correctly ordered output (one which we aren't going to get) that even if the code does work this way, there is no way to have any amount of confidence in solutions using this function (where the ordering is important) because there could be edge cases that are difficult to test for (or at least impossible to know about), or undocumented changes that could alter the behavior.
Fair enough. I guess we do need a guarantee of some sort, either in writing (not gonna happen) or via an ItemNumber column. But for the record, I was never arguing against the desire to have this suggestion implemented. I guess I didn't state that here, but I did say in that Connect suggestion that I agreed with the suggestion (and voted for it) and was proposing a short-term work-around. Though I suppose now that without a stated guarantee, that it can't be ruled out that there is at least one edge-case that violates this expectation, such that my proposal really isn't a workable work-around, even in the short-term. In which case I would now agree that this function is probably too risky to use in cases where there is a functional dependency on the ordering.
You should add that revelation to the CONNECT item, if you haven't already. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2016 at 4:53 am
Jeff Moden (3/20/2016)
spaghettidba (3/17/2016)
I had the same issue in the past, both with VMs and my laptop, where I partitioned the disk a bit too aggressively...What I ended up doing is moving all the updates (C:\windows\Installer) to a second drive and creating a symbolic link from c:\windows\installer to d:\windows\installer
Oooooo.... you've got to tell me how to create that "symbolic link", Gianluca. That would solve a wealth of sins where I work.
The command is mklink. Fairly easy to use.
You move the folder to a different disk then create a link with mklink.
-- Gianluca Sartori
March 21, 2016 at 7:59 am
Brandie Tarvin (3/21/2016)
For those of you with standing desks, ArsTechnica says it may not be helping[/url] you at all.
...and 'they' said margarine was better for you. Oh wait, it's butter again!
Although I agree that sitting at a desk for 8+ hours a day certainly doesn't help, I'm not so sure standing is leaps and bounds better. In the end I believe it's about finding balance in you work/active life.
March 21, 2016 at 8:00 am
March 21, 2016 at 8:01 am
spaghettidba (3/21/2016)
Jeff Moden (3/20/2016)
spaghettidba (3/17/2016)
I had the same issue in the past, both with VMs and my laptop, where I partitioned the disk a bit too aggressively...What I ended up doing is moving all the updates (C:\windows\Installer) to a second drive and creating a symbolic link from c:\windows\installer to d:\windows\installer
Oooooo.... you've got to tell me how to create that "symbolic link", Gianluca. That would solve a wealth of sins where I work.
The command is mklink. Fairly easy to use.
You move the folder to a different disk then create a link with mklink.
Is there a specific reason to create a Junction Point (via "/J") instead of a Directory Symbolic Link (via "/D")? I am just curious. From everything I have been reading, it seems like Junction Points are essentially deprecated and offer no benefit over actual Symbolic Links. So I am just wondering if you have found a specific reason to use a Junction Point as none of the documentation or blog posts on this topic address this specific point, at least not clearly ;-).
SQL# — https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
Sql Quantum Lift — https://SqlQuantumLift.com/ ( company )
Sql Quantum Leap — https://SqlQuantumLeap.com/ ( blog )
Info sites — Collations • Module Signing • SQLCLR
March 21, 2016 at 8:07 am
Quick question: I got the standard email saying that someone replied to a comment on one of the forum threads but when I go to that thread the comment is not there. I commented last at like 11:50PMish... then I have two emails saying they replied at 2:09AM and 2:30AM but when I check the thread my comment is the last one.
Just weird, something I have not seen before.
-- Itzik Ben-Gan 2001
Viewing 15 posts - 53,101 through 53,115 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply