Viewing 15 posts - 6,661 through 6,675 (of 59,098 total)
Anything that you write for code can be changed by anyone with SysAdmin privs. No pun intended, but if you want the STIG to "stick", you're going to have to...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2020 at 12:08 am
It has no dependencies because it sorts the values again (as I understood the q). If you have a lot of data that has already been sorted, that may...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 4:56 pm
This is one of the reasons why I use RAISERROR('Section: %s Duration(ms): %u',0,0,@SectionName,@Duration) WITH NOWAIT: in virtually ever section of stored procedures I write to write section name, duration and,...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 1:32 pm
I have a standing offer on LinkedIn to promote anyone looking for work. I'll double down on that for Threadizens. I can actually say I know that you know...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 1:20 pm
Step 1, get a much nicer picture for linked in and smile a little bit.
Step 2, update your recent history and make sure you list your major accomplishments!
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 3:58 am
p.s. And what I was getting at is you could do your RowNum at the same time if you really need it but I'm thinking that sorting by ID is...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 3:02 am
Ok... give this a try and let me know if this does the trick or not. I left your RowNum in there instead of sorting by the ID. I think...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 2:27 am
Yes that's correct. In the new dataset I renamed RIN# to Cl_ID and License# to VEH. But yes, you would be correct.
Ah.. ok. Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 1:55 am
There are definitely rows without dupes. And in the full dataset that's the vast majority. Any records that have a 1 rownum, (which are not followed by a 2...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 1:54 am
And, to be sure, you said the following columns are what you used to identify dupes?
,ldate
,RIN#
,Provider_Name
,License#
,pick_up
,drop_off
,Modifier
,CALCULATED_FARE
If that's true, then there's trouble in paradise because there is no RIN# or License#...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 1:45 am
but I ran the code Scott provided against this dataset and it still works, pulling up two sets of 3 dups. I'm stumped.
Oh no... I'm NOT saying that Scotts...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 1:27 am
It missed about 4 records which had triple matches...
This is what I'm trying to get at. If you used the old standby of using ROW_NUMBER() to find dupes and...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2020 at 12:08 am
try adding firstrow option to start data at row 2 - row 1 is headers so it would blow the size of the columns you defined on that table.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2020 at 6:48 pm
Actually, I used all of the values listed in the table as the values which identify duplicates (those are what the Row_Number used to create the RowNum column). Does...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2020 at 6:38 pm
I had the requirement to put on auditing. I made the server specifications, put in a file, and read the file info a database only the security officer can...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2020 at 6:03 pm
Viewing 15 posts - 6,661 through 6,675 (of 59,098 total)