Viewing 15 posts - 16,621 through 16,635 (of 59,067 total)
Rechana Rajan (10/16/2016)
declare @0 bigint,@1 bigint,@2 varchar(50),@3 bit,@4 varchar(50),@5 datetime2(7),@6 varchar(50),@7 datetime2(7)
INSERT [dbo].[Transaction]
([TransactionId], [ConId], [TransactionStatus], [Status], [CreatedUserId], [CreatedDate], [UpdatedUserId], [UpdatedDate])
VALUES (@0, @1,...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 16, 2016 at 3:41 pm
Heh... crud. JLS is faster then I am. His post wasn't there when I started mine.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 15, 2016 at 2:36 pm
This should do it...
SELECT tbl.CKey, ca.VX
FROM #Counter tbl
CROSS APPLY (SELECT MAX(VX) FROM (VALUES (CA),(CB),(CC),(CD),(CE))v(VX))ca(VX)
;
The FROM (VALUES) combination in the CROSS APPLY effectively unpivots each...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 15, 2016 at 2:35 pm
Heh... forget the old stuff. It'll persevere and someone somewhere will know how to fix it or be able to science it out. It's a part of why it's...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 15, 2016 at 2:24 pm
naren.ece2012 (10/15/2016)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 15, 2016 at 2:17 pm
I would never use CHECKSUM for such a thing. It's much too easy for it to equate two things that are not equal because it's just a simple binary...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2016 at 5:40 pm
whenriksen (10/14/2016)
SELECT COUNT(*),
CAST(DATEADD(WEEK, DATEDIFF(WEEK, '20061231', DATEADD(DAY, 7
- CASE DATEPART(WEEKDAY, o.modify_date) WHEN...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2016 at 5:33 pm
ScottPletcher (10/14/2016)
whenriksen (10/14/2016)
First day of the business week is Monday.What do you recommend?
I posted code that did that type of calc already. What specifically are you trying to list?
If...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 14, 2016 at 5:28 pm
CELKO (10/13/2016)
But a better question is why is a date, which is an attribute of an entity, being used as metadata?
It's probably not applicable for this thread but the...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2016 at 7:04 pm
This sounds like the Kerberos Double-Hop problem. What happens when someone with sysadmin privs runs the code from the server itself?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2016 at 6:51 pm
There are other "data security" matters, as well. You need to consider backups and where they live as well as "data at rest". That goes for both SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2016 at 6:29 pm
hegdesuchi (10/13/2016)
I have a request where i have to check if ID exists ,If ID exists then update. However client wants to evaluate each field from source and check if...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2016 at 6:21 pm
ps_vbdev (10/13/2016)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2016 at 6:09 pm
komal145 (10/13/2016)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2016 at 5:56 pm
niall5098 (10/13/2016)
HI Jeff,the original table does have a modified column so the idea is I would querying for data which has a modified date > getdate()-1
I'm certainly not an XML...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 13, 2016 at 9:20 am
Viewing 15 posts - 16,621 through 16,635 (of 59,067 total)