Viewing 15 posts - 2,296 through 2,310 (of 59,086 total)
"It Depends" on what you're talking about. If you're on Eastern Time and you want the correct data based on a UNIX timestamp, then you need to convert your local...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 4:47 am
I am not even sure what your function is trying to do here - or why you would even care about UTC. The UNIX timestamp is an offset in...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2022 at 2:47 am
The new STRING_SPLIT with the 3rd operand is great for this. The old STRING_SPLIT without it is not. Even MS has stated that the order of the output is NOT...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2022 at 9:27 pm
And what kind of stored procedure? Is it for DBAs/Maintenance, etc or is it "production" code or ???
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2022 at 9:18 pm
Agreed.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2022 at 9:01 pm
So make call in open query to get the int value of t_stamp then use that as the driver in query..
If I'm understanding what you wrote above correctly (it's...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2022 at 8:27 pm
Most of these are not SARGable. I wonder if the TIME conversion is (Like DATE and DATETIME supposedly is).
If this is a regular thing, I'm with Piet... persisted computed column.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2022 at 11:45 pm
Hi jeff thanks for advice , i went by website you suggested geeks for geeks and i found it to more for programmers . .I didnt see anything related...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2022 at 11:39 pm
Thanks for the update, Steve.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2022 at 11:29 pm
And, I didn't read Jeffrey Williams post before I posted (I was responding to a post on the first page of this thread). He's spot on about the Unix TimeStamp...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2022 at 10:41 pm
Insert Into Tag_Data_Capture_staging
(TagName,CaptureValue,DateRecorded)
select *
from OPENQUERY(srv1, 'select tagid,floatvalue,DATEADD(s,t_stamp/1000,''1969-12-31 20:00:00'') from rem.ignition.dbo.sqlt_data_1_2021_12
where DATEADD(s,t_stamp/1000,''1969-12-31 20:00:00'') between ''12-09-2021'' AND ''12-10-2021'' and floatvalue is not null');
I did the Insert...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2022 at 10:27 pm
Jeff- I agree. I was too hasty in my initial thought process. Change is inevitable. Change of thought for better is not 🙂
😀
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2022 at 12:30 am
@cbarus - I CAN definitely understand not wanting to mess with a legacy app or it's database especially when they're out of support. I was just confused by your posts...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2022 at 5:21 pm
Thanks for the feedback all. No, no hate on Trace. I was dead serious in what I said about never questioning anyone using it ever again. Also, equally serious...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2022 at 5:15 pm
And, in case you're wondering what the chart looked like that I needed (and sound like what you want) here's what I ended up making. The Red lines show the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2022 at 6:29 am
Viewing 15 posts - 2,296 through 2,310 (of 59,086 total)