Viewing 15 posts - 7,861 through 7,875 (of 59,072 total)
I'm thinking that SEQUENCE is going to be about 4 times slower. That's just a guess.
Sounds crazy but this is fascinating to me because I work with some really large...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 4:04 pm
BAAA-HAAAA!!! Step 1 is to ask them how to get the current date and time in T-SQL. 😀
Of course, when you do find an expert, can you actually use them...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 2:20 am
No. I'm NOT recommending that you set a MB value the same as the MDF/NDF for LDF although they can be set the same. "It Depends". On what?
The LDF file...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 12:36 am
Thanks everyone. I have added a clustered primary key in our test environment but can't compare the performance as the configuration is totally different. When I do the 300...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2020 at 12:33 am
This is really the same as a "Catch-All" query. Why not write the dynamic SQL to do it?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 11:05 pm
It's all in that link: https://www.brentozar.com/pastetheplan/?id=SJF21m0lU
INSERT INTO @retTable
SELECT c.ClaimID, cd.ServiceCode, c.ServiceDate, cd.ServiceQty, c.CareProviderID, ISNULL(cd.DiagnosticCode, c.DiagnosticCode), c.SpecialtyCode AS Speciality,
sg.GroupCategory AS ServiceCodeGroupCategory, 0, NULL
FROM...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 11:00 pm
I think something like this is what you're looking for...
SELECT *
FROM sys.dm_db_index_usage_stats x
JOIN VendorDB.sys.indexes i
...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 10:53 pm
sys.dm_db_index_usage_stats covers all of the databases no matter which database you call it from. You have to identify the database_id in your query.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 10:49 pm
Hmm, maybe I misunderstand, I thought the OP said that it was just that one query for the max date, ~ every hour, in order to provide that...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 9:19 pm
As a bit of a sidebar, why not just use the Developer's Edition for evals? So long as you never use the Developers Edition for production, it's legal.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 9:09 pm
Yes, because MONEY is a precise data type with 4 decimal places. It's implemented as a 64-bit integer, scaled down by 10000. That and DATETIME must be the two...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 7:30 pm
We're getting a bit lost here because I wasn't clear my last post. I'm thinking this isn't the only query that will be played against the column.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 7:20 pm
Given that the table had no index at all, I didn't think in this case that making the clus index unique was necessary, particularly to the extent of adding...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 4:24 pm
That being said, I'd love to see the schema of the table and what the real use of finding the max date would be for this table.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 4:15 pm
Adding to Lynn's post, I will say that having a UNIQUE Clustered Index is usually better because it gets used in all Non-Clustered indexes, as well.
To wit, I do have...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2020 at 3:38 pm
Viewing 15 posts - 7,861 through 7,875 (of 59,072 total)