Viewing 15 posts - 6,631 through 6,645 (of 59,072 total)
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
Which columns are used to determine if a row is a duplicate or not? I'm not talking about after you use ROW_NUMBER() to mark them... I'm talking about what did...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2020 at 6:01 pm
Viewing 15 posts - 6,631 through 6,645 (of 59,072 total)