We have a problem affecting the production environment only.
We have a VB6/ASP website that allows for data in a database table to be hand edited.
It looks alot like an editable datagrid.
One of the editable columns is a date and when the record is saved dates day/month are being reversed.
03/11/2008 becomes 11/03/2008, if you were to resave the record the date is again 03/11/2008.
I have checked the DB value and it is indeed being reversed however the same identical code on the test systems does not do this.
So i'm very confident i'm looking for an environment change. The test system has the DB and Site hosted locally and in the live setup we have a separate web site server and database server. Where do you suggest I start looking for this problem. I've checked the regional settings on the servers and they are set to United Kingdom and the OS date format is correct.
This is SQL Server 2000. hit me with some ideas!.
Thanks :)
If you convert the user supplied string to a date before you feed it to the DB, then the Session.LCID of the thread executing your ASP page is responsible for how dates are interpreted.
If you feed the date as a string to SQL Server and let the conversion happen there, it will be useful to look into the SET DATEFORMAT and the SET LANGUAGE statements.
So here is my idea: Either stop using (encouraging your users to use) ambiguous date formats, and this problem will disappear, or make sure all links of the processing chain have a clear understanding on what format to expect.
This is almost certainly to do with either your machine or the db server being set to US date format. Double check both the system settings.
Alternatively, a quick Google search will bring up a few options for manipulating the data so it will do what you need.
How about the regional settings of the OS?
The following
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
Returns the same result on test and live
us_english English mdy
The problem is the system cannot be redeployed to changed. I need to identify the cause and fix it.
Go into regedit and go to the following location in the Windows Registry:
HKEY_USERS.DEFAULT\Control Panel\International\
Check to make sure that the "sShortDate" field is correct.
The short date format stored in this location many times is different then the short date format stored in the Windows Control Panel/Regional Options. The short date in the regional options is for the user that you are logged into Windows as. The "sShortDate" field in HKEY_USERS in the short date format used by the Windows Services.
Related
I am building a tool which displays Skype persistent chat information along with participants information. For one of the requirement, I need to filter the tblComplianceParticipant table in a given date range.
I tried many different approaches to convert tblComplianceParticipant.joinedAt column to human-readable format like 'yyyy-mm-dd', etc. but no luck so far. Data in this column are 18 digit numbers, starting with "63" for example 636572952018269911 and 636455769656388453.
These values are also not in 'windows file time' format because https://www.epochconverter.com/ldap gives the future dates with above values.
I tried looking at #JonSkeet's answer on 18 digit timestamp to Local Time but that is c# specific. I tried to replicate similar logic in SQL but no luck.
Is there any way to convert this 18 digit numbers to normal date format and perform where clause on it?
Online converter which gives desired output: https://www.venea.net/web/net_ticks_datetime_converter#net_ticks_to_date_time_and_unix_timestamp_conversion
However, I was looking for underlying logic to convert it myself as I need to perform where clause on it in SQL server stored procedure.
Our Skype administrator provided me with a SQL function (fnDateToTicks) which was part of Skype database (mgc) (Earlier, I didn't have permission so could not see it). I am verifying with him whether it is an internal IP or standard solution by Microsoft so I can share it with the larger community.
The only thing i can think is worth trying:
select CAST ([Timestamp Column] as datetime)
Which will format it as yyyy-mm-dd 00:00:00:000
This may work for SQL Server 2008 and onwards
I have been researching a lot of similar questions on how to convert date format to DD-MM-YYYY but none work for the date format I'm using.
This is the date format I'm working with:
Wednesday, October 14, 2015 5:57 PM
And this IS a "date" field not a text field. I have a feeling that the inclusion of the day of the week is precluding my other attempts from working.
I'm new to SQL so forgive me if I'm overlooking something obvious.
Thank you!
On SQL Server, there are generally four ways to control date formatting.
Control it in your application. Most queries to the database return result sets that are typed. So a datetime column will be of data type datetime or timestamp in your application. You then apply the formatting from your application. The drawback to this is that, well, you wouldn't be asking this question if this were your problem.
Use the CONVERT() function, which allows limited formatting of datetime, datetime2, date, and time fields. SELECT CONVERT(VARCHAR(10),GETDATE(),103) will format the column to dd/mm/yyyy. The drawback to this is that you have to do it for every field you want to format every time you want to format them, and you lose the data typing since you're actually converting them to strings.
Use the SET DATEFORMAT command or the SET LANGUAGE command prior to executing your query. You can execute SET DATEFORMAT dmy; SELECT GETDATE() and your dates will be in dmy format. The drawback here is that you have to run it every time you run a query. Also note that since this returns your columns with data type intact, it's possible that your query analyzer will reformat the dates on you.
If you want to permanently set the date format, then ultimately you need to change the language away from us_english (or whatever the default was that was specified when you installed the server). You can see the list of available language configurations by running exec sp_helplanguage, and you can see the currently configured language for your session by running SELECT ##LANGUAGE. I know it's possible to set up your own languages if you need to, but be aware that's a custom configuration you'd have to deploy if you're running that kind of application.
Language configuration is potentially very complicated, since it's determined by the user, login, database or server, depending on where exactly it's specified. As far as I'm aware, logins inherit the server's default language, and users inherit the database's default language. User language is usually not specifed, but I believe it overrides the login language when present. I've only ever run in configurations where everything was defaulted to us_english, so I've not had much experience with this set up. You can modify it with ALTER LOGIN or ALTER USER, and you can set the default language on the server with sp_configure and on the database with ALTER DATABASE.
I have a vb6 application and it linked to an MS SQL Database via Windows DSN. The application is using rdo connection to connect to the database and tables. Recently my users upgraded their OS to Windows 7. Now they have an issue with the dates whenever they do a posting or updates. Although the system default short date format is set as dd/MM/yy, the application keeps posting the dates to the database as mm/dd/yyyy.
The strange thing is that within the codes the date has already been formated per below
rsPO("LAST_UPDATED_DATE") = Format(Now, "DD/MM/YYYY hh:mm:ss")
so why is it still saving the date as mm/dd/yyyy?
Try with ISO format date. It is a universal date format and works in all DBs
rsPO("LAST_UPDATED_DATE") = Format(Now, "YYYY-MM-DD hh:mm:ss")
Dates are not saved in "dd/mm/yyyy" or any other particular format into the Database.
You just should make sure to use a format to save it in the same manner understood by the application, the OS and the DataBase
Then you can show it the format that you like.
ISO format works ok in most cases.
Date interpretation is a language thing. It's not set by the language on the client computer. It's set by the language of the login making the connection to the SQL database. There are a couple ways you can change things so that it is language independent.
Since LAST_UPDATED_DATE is a DateTime, you should be able to do this:
rsPO("LAST_UPDATED_DATE").Value = Now
If not, then you should format your dates like this: YYYYMMDD.
rsPO("LAST_UPDATED_DATE") = Format(Now, "YYYYMMDD hh:mm:ss")
Read more about it here: Setting a standard DateFormat for SQL Server
To make our developers into the context. The problem is not with stored Date in the database, but the problem happens when we call select for example select * from ... where Date_import ..... This date_import is getting into the database with the format mm-dd-yyyy by default. So the problem is with the String request SQL and not at all with your code or with how data is stored. The solution is to set all your code with YYYY-MM-DD instead of DD-MM-YYYY.
I’m having a problem with a linked Informix table in MS SQL Server 2008r2. When I query this table, it seems to ignore some of the criteria I’m passing to it but not others. For example if I put a condition on the rowdate field the remote query part of the execution plan does not show any WHERE clause but if I put criteria on another field such as ACD it does show.
It seems it does not pass any criteria on the rowdate field but does on all others.
I know the field is indexed on the Informix side. If it helps the table I’m linking is from Avaya CMS and it is linked via the OpenLink ODBC driver.
EDIT:
As far as I know it is Informix Dynamic Server 2000 and it is on Solaris. The column comes up as a DATE data type which is correct. I have tried passing the criteria as ‘2010-08-03 00:00:00’, ‘2010-08-03’, CONVERT(date,’2010-08-03’) and a few more variations. When the data is returned to SQL server it is in the format yyyy-mm-dd.
When I view the execution plan I can see the remote query with all the other criteria followed by a filter for only the rowdate field.
I know that rowdate is indexed and that the driver does normally communicate that information as we use it in other applications (Business objects and MS Access) and they don’t have a problem
I managed to figure it out but it is the strangest thing ever. I went down the route of passing the date in different formats. My default is to use the normal YYYY-MM-DD that of course did not work so I tried YYYY-MMM-DD, still nothing. After going through LOTS of combinations I found one that works Mmm-DD-YY and it has to be exactly that! SEP-21-2010 wont work but Sep-21-2010.
I wonder if this is just a strange hang up from Informix or something in the driver, anyway it works.
On a side note has anyone noticed how strange it is that people from the America write the date month, day year? Stop and think about it for a second, do you say the number 2410 as “Four hundred, ten, two thousand”? The best part about it is try asking yourself this, what day is American independence day? Most Americans say “That’s easy you limey person it is the 4th of July” hmmmm day month (year), the only date they say round the right way is the date they got their independence. I will leave it up to the SO community to see the irony in that
Example query below:
select *
from OPENQUERY (AVAYA, 'select row_date,starttime,intrvl,acd from root.hagent where
row_date = ''NOV-22-2012'' and acd = 1 and split = 1 and starttime = 1900')
By the way I managed to extract accurate data via both MMM-DD-YYYY and Mmm-DD-YYYY.
Scenario: We have a great deal of server environmental information (names, IPs, roles, firewall ports, etc.). Currently it's stored in a big Excel workbook on a SharePoint, which trivially allows for side-by-side comparisons of past versions of the data with current, for example.
we're planning to move it into a SQL Server 2008 database to make it easier for tools/automation to tap into as well as for better reporting. However, as you'd expect, one of the requirements given was that the admins would like to be able to see how an environment looked at some point in the past. Some piece of magic like: sp_getEnvironmentsAsOf('PERF1', '2009-11-14 00:00:00') and suddenly all the data that was current as of 11/14/09 is returned.
I'm looking into SQL Server 2008 Change Tracking and Change Data Capture, but all of the scenarios and examples don't see to relate to the specific requirement of seeing the data in the tables as they were at some arbitrary point in the past.
Is CT/CDC apropos? And what are the other options, beyond rolling my own solution out of ticky-tacky and hope?
You should design your schema to track this changes instead of relying on a dbms feature. Something like:
Devices
Id
Description
Serial number
Some immutable properties
Properties
Id
Description
Device-Properties
DeviceId
PropertyId
Value
TimeStamp
You never update or delete Device-Properties, you only add rows with a new timestamp.
Sample Data:
Devices
1,Server A,1123123
2,Server B,1323454
Properties
1,IP Address
2,Location
3,Rol
Devices-Properties
1,1,192.168.0.10,2010-02-12
1,2,Rack D,2010-02-12
1,3,Proxy,2010-02-12
2,1,192.168.0.105,2010-02-12
2,2,Rack C,2010-02-12
2,3,Mail server,2010-02-12
1,1,192.168.0.11,2010-02-15
In the sample data, Server A IP address was changed from 192.168.0.10 to 192.168.0.11 on 2010-02-15
You can construct views or stored procedures to join and filter the data as needed.
CDC is appropriate but you might also want to look at AutoAudit on CodePlex.
What comes to my mind is 'snapshot' feature (snapshot shows you a state of you database at the time snapshot is created). However, snapshot looks like a different database (so you will query something like 'MyDBSnapshot_DATE' instead of 'MyDB' and it definitely takes resources [to track changes].
Other option is ... do it yourself.