This is more of a question than a problem as our production system is working as intended.
I am relatively new to the SQL environment. I've been poking through various configurations on the server just to get myself familiarized with the system. One thing that I noticed is the mail queues seem to use the UTC time instead of the local time. For example, if I run
exec sysmail_help_queue_sp
The last empty_rowset_time column shows a time that is exactly 12 hours behind the value getdate() returns (I am in New Zealand) and happens to coincide with the value of getutcdate(). I was more than a little surprised to say the least. The server is configured with the correct time zone (Auckland/Wellington).
I have made sure that the value(s) in the last_empty_rowset_time is indeed updated every time I sp_send_dbmail.
Does anyone know why this is the case? I am just curious to know. I do apologize for my newbiness if this sounds obvious to some of you.
Thanks.
James
This isn't something that is affected by local configuration. Based on documentation here:
http://msdn.microsoft.com/en-us/library/ms187400.aspx
Microsoft explicitly states "military time format and GMT time zone". If you want to see it in your local time zone you'll have to modify your query as such.
Related
I know there is a system function to get the host name - which returns the Server Name (Application server name in my case).
SELECT HOST_NAME()
Is there a similar function like HOST_TIME() to get the time of application server?
Or is there any workaround at database side to get the time of application server when a procedure is called?
This doesn't sound like a database question to me. You should have the application pass along a timestamp along with whatever query is getting sent along to the database server.
If you must define this at the database level, why don't you simply add the time zone difference? I'm not sure where you're located, though here in the US if I had that issue I would simply do at GETDATE() and then use DATEADD to adjust to the timezone of the other table. The only thing which you would need to spend some time on would be what to do when the time changes (daylight savings time etc.). In my case, none of our users use our system at that hour, though that may be different in your case.
Good luck, and let us know what happens.
I'm using SQL Server 2016 at Amazon AWS. My emails are being sent with incorrect times when sent from my pupper at Amazon. When I try to recreate this bug locally the times are correct. Here is an example of how I use at time zone.
getDate() at time zone 'utc' at time zone u.timezone
where u.timezone is the user's timezone and u refers to an aliased table users.
The times being outputted are at UTC time, so I see 7:36pm instead of 2:36pm (they are formatted with MomentJS)
I don't really know where to start with this one, sorry guys and gals.
UPDATE
My server is sending the correct time (with the correct timezone offset) to the email factory. When the server creates the emails, times are formatted using MomentJS. The barebones moment() function will take a time with a timezone offset (-5:00) and adjust it to the local machine's local time. Local time on my machine is EST, but in Amazon (where the email is being created) is not. Thus I must use moment.parseZone().
From the MomentJS docs:
If your date format has a fixed timezone offset, use moment.parseZone:
moment.parseZone("2013-01-01T00:00:00-13:00");
This results in a date with a fixed offset:
"2013-01-01T00:00:00-13:00"
Since I can't see this change until it is pushed onto our dev environment, I won't be able to know if this fixed it, but I think this was the problem.
My server was sending the correct time (with the correct timezone offset) to the email factory. When the server created the emails, times were formatted using MomentJS.
The barebones moment() function takes a time with a timezone offset (-5:00) and adjusts it to the local machine's local time.
Local time on my machine is EST, but in Amazon (where the email is being created) is not. Thus I must use moment.parseZone().
Changing to moment.parseZone() fixed this issue. Problem solved.
When I Use the below code:
Dim cmd As New OdbcCommand("SELECT GETDATE()", oConn)
retVal = cmd.ExecuteScalar()
The resulting output is:
8/1/2013 10:10:39 AM
When I run the exact same query directly in Management Studio I get:
2013-08-01 10:10:39.317
When I check my computer settings versus the SQL Server settings they match.
Anyone know what I need to do to ensure it matches?
Specifically I am talking about the Date format difference.
If you want the date output with a specific string format, then you can use CONVERT() with a style number. For example:
SELECT CONVERT(CHAR(20), GETDATE(), 22),
CONVERT(CHAR(23), GETDATE(), 21);
Results:
-------------------- -----------------------
08/01/13 10:53:54 AM 2013-08-01 10:53:54.943
However, if you are using the date for things other than direct display, only apply that formatting when you are displaying it. For all other purposes it should remain a datetime type and should not be converted to a string.
As for the differences in the actual time value, it's not clear what problem you're talking about, but I suspect you simply ran these queries half an hour apart. If those were run at or around the same time, it looks like the server is half an hour fast - maybe it's in a different time zone or maybe it's just a lot of drift or someone not bothering to use a time service. Your application should never use the time / time zone of the client, especially if it's distributed - always use the time on the server.
Dates have no format. Format comes into play only when you convert dates to a string. The forma used depends on who does the conversion: the server or the client?
Your VB.NET query returns a date from the server and converts it to a string when you write it to the console, a form or whatever. VB.NET uses your programm's CurrentCulture, whose defaults come from the current user's regional settings.
When you display data in SSMS, an ISO format is used so there is no ambiguity when you edit the data.
When you compare date and string values in a query, either explicitly by converting a date to a string or implicitly because you just typed MyDate = '13/1/2013, a conversion is made using the column's collation. Collations are inheritted so the column's collation is the same as the database's collation.
Try this:
net time \\SERVER_NAME
Note: Obviously SERVER_NAME is the name of your SQL Server machine.
Do you see a 30 minute difference in the result of that call?
I looked deeper into the code and found that some enterprising fellow had added code to a line of SQL later in the process which forces DMY format on that query.
so the code in the VB is returning the proper Date on the app machine. Which means that there must be a difference between my computer and the app machine.
Another coder ran into the same issue and so there solution was to add the below code to the SQL that was pulling from the DB.
SET DATEFORMAT dmy
This forces the SQL to use DMY format... I removed this code Compiled and ran the EXE from the server machine and my issue dried up!
Thanks for everyone's help.
I'm working with a moderately sized database of about 60,000 records. I am working on building a mobile application which will be able to check out a single table into a compact .sdf on for viewing and altering on the device, then allow the user to sync their changes back up with the main server and receive any new information.
I have set it up with the Sync Framework using a WCF Service Library. When setting up the connection for some reason the database won't let me check "Use SQL Server Change Tracking" and throws up the error:
"'Unable to initialize the client database, because the schema for table 'Inventory' could >not be retrieved by the GetSchema() method of DbServerSyncProvider. Make sure that you can >establish a connection to the client database and that either the >SelectIncrementalInsertsCommand property or the SelectIncrementalUpdatesCommand property of >the SyncAdapter is specified correctly."
So I leave it unchecked and set it to use some already created columns "AddDateTime" and "LastEditTime" it seems to work okay, and after a massive amount of tweaking I have it partially working. The changes on the device sync up perfectly with the database, updates, deletes, all get applied. However, changes on the server side...never get updated. I've made sure everything is set up right with the bidirectional setup so that shouldn't be the problem. And, I let it sit overnight so the database received ~500 new records, this morning it actually synced the latest 24 entries to the database...out of 500 new. So that should be further proof that it's able to receive information from the server, but for all useful purposes, it's not.
I've tried pretty much everything and I'm honestly getting close to losing it. If anyone has any ideas they can throw out I can chase after I would be most grateful.
I'm not sure if I just need to go back and figure out why I can't do it with the "SQL Server Change Tracking". Or if there is a simple explanation for why it's not actually syncing 99% of the changes on the server back to the client.
Also, the server database table schema can't be altered as a lot of other services use it. But the compact database can be whatever the heck in needs to be to just store the table and sync properly in both directions.
Thank you!!
Quick Overview:
Using WCF and syncing without SQL Server Change Tracking (Fully enabled on server and database)
Syncing changes from client to server works perfectly
Syncing from server back to the client not so much: out of 500 new entries overnight, on a sync it downloaded 24.
EDIT: JuneT got me thinking about the time and their anchors. When I synced this morning it pulled 54 of about 300 new added records. I went in to the line (there are about 60 or so columns, so I removed them for readability, this is kind of a joke)
this.SelectIncrementalUpdatesCommand.CommandText = #"SELECT [Value], [Value], [Value] FROM >TABLE WHERE ([LastEditDate] > #sync_last_received_anchor AND [LastEditDate] <= >#sync_new_received_anchor AND [AddDateTime] <= #sync_last_received_anchor)";
And replaced #sync_last_received_anchor with two DIFFERENT times. Upon syncing it now returns the rows trapped between those two and took out the middle one giving me:
this.SelectIncrementalUpdatesCommand.CommandText = #"SELECT[Value], [Value], [Value] FROM >TABLE WHERE ([LastEditDate] > '2012-06-13 01:03:07.470' AND [AddDateTime] <= '2012-06-14 >08:54:27.727')"; (NOTE: The second date is just the current time now)
Though it returned a few hundred more rows than initially planned (set the date gap for 600, it returned just over 800). It does in fact sync the client up with the the new server changes.
Can anyone explain why I can't use #sync_last_received_anchor and what I should be looking for. I suppose I could always add box that allows the user to select the date to begin updating from? Or maybe add some sort of xml file to store the sync date that would be updated anytime a sync was -successfully- completed?
Thanks!
EDIT:
Ran the SQL profiler on it...the date (#sync_last_received_anchor) is getting set to 8 hours ahead of whatever time it really is. I have no idea how or why it's doing this, but that would definitely make sense.
Turns out the anchors are collected like this:
this.SelectNewAnchorCommand.CommandText = "Select #sync_new_received_anchor = GETUTCDATE()";
That UTC date is what was causing the 8 hours gap. To fix it either change it to GETDATE(), or convert your columns to UTC time in the WHERE clause of the commands.
After spending many hours with many cups of coffee, I've figured out how to solve this error of mine. While I was running the code on desktop testing area, everything seemed to be working perfectly; however the same code and webservice on target device gave this error repeatedly. Then, suddenly, the "dbo_" prefixes on compact database table names started looking interesting, like they were trying to tell me something really important. So, I've listened...
Configuration.SyncTables.Add("Products);
on ClientSyncAgent.cs should be changed to
Configuration.SyncTables.Add("dbo_Products");
[Exeunt]
We have a bunch of T-SQL scripts dependent on today's date and when they run. If one doesn't run on the week it should, we end up temporarily setting the system time a day before, run the script, then set it back.
Is there anyway to temporarily set the system date for a script without changing the original script, like when you execute it or only for that session?
You could store the actual date in a table / temp table.
THen retrieve or update that date rather then making a call to GetDate().
I've found an answer by someone else, here I share it: "The date is tied to the OS date and time. See here: http://msdn.microsoft.com/en-us/library/ms188383.aspx".
You could refer to this other question Simulate current date on a SQL Server instance?