I transfered data from our old SQL Server 2000 (SBS 2003) to another server running SQL Server 2008 r2 (Server 2008 r2 standard).
The data was transfered, but now the dates in the different tables are messed up.
Is there a special procedure I need to follow in order for the date column to transfer correctly. If memory servers, date columns are soted as an offset.
Anyone know how to correct this?
I tried looking it up, but couldn't find an answer. Maybe I just didn't think of the correct key words.
Thanks!
Edit: What I mean by messed up is that the original date (from the old server) is 2011-05-08 and the new date (from the new server) is 2010-04-14. I tried to see if there is a common offset for all he moved dates, but couldn't find one.
Are you sure you don't have the Old (2011 dates) / New (2010 dates) backwards? It sounds like you just aren't including the date column in your INSERT, and it has a default of GETDATE(), so it has the current date getting inserted. Or there is some trigger changing the value from what you specify to the current date. To verify, do your SELECT..INSERT into a new or temp table and see what you get.
Related
I have MS Access which is linked to SQL Server
I'm typing on a keyboard with Kurdish Central layout.
Data in SQL Server is no problem, but in MS Access it's showing a column as
#Deleted
This problem is only in Kurdish.
What is the solution to this problem?
Thanks for everything ...
I don't believe this has ANY relevance in regards to the language used.
Make sure the server table has a PK id, and also add a row version column to the sql server table. (row version is called timestamp - but has ZERO to do with time - worlds worst name in history for a column type in sql server).
So, ensure the sql table has a PK column defined, and also that timestamp column. Now, rel-link the access table and try again.
We recently moved our database from SQL Server 2005 to 2014. But now we are having an issue with how the server converts datetime from varchar.
Previously, a date string 2017-06-30 was converted correctly as July 30, but now even with the user and the database with the language set to Spanish, it still converts the date format as yyyy-dd-MM.
Is there some way to permanently change the configuration to fit the original one? One work around we found was to add SET LANGUAGE ymd at the beginning, but the amount of procedures doesn't make this feasible in a timely manner.
MSDN lists "TIME" as an available Data Type. This is good, since I need time variables and the ability to perform functions on them (in the form of 00:00:00). Datetime is not an option because my scheduling database cares about Monday - Sunday, not 11/13/14, etc... When i go to create a column with data type time, it doesn't exist. I also tried doing it via query:
ALTER TABLE dbo.DataSchedule
ALTER COLUMN StartClock TIME
And get the message:
Msg 2715, Level 16, State 6, Line 1
Column, parameter, or variable #6: Cannot find data type TIME.
How can I resolve this issue? Is this a problem with 2014 express as opposed to the standard edition?
Thanks for reading.
Per SQL Server documentation TIME datatype is available from SQL Server version 2008 and above. I am pretty much sure that, you connected to a SQL Server 2005 instance and tried using the TIME datatype.
Also, it doesn't matter which SSMS version you are using to connect to since that's just the client. Make sure that, you are actually connected to a server version 2008 and above.
Anyone know of any temporal (http://en.wikipedia.org/wiki/Temporal_database) extensions to SQL Server?
I know this is an old question, but the usual solution in SQL Server is to create a "Date Dimension" database that you can join in your query. A DateDim is basically just a list of dates, but it includes columns like fiscal quarter and calendar quarter number, first/last day of that month, etc.: stuff that's difficult or time consuming to calculate on the fly but is easy to pull from a joined table.
If you search "sql date dimension" you'll find some code that will generate the table for you, though you'll need to tweak it to fit your needs. They tend to run day-by-day, but if you need hourly tracking you'll need to alter the code accordingly, for example.
SQL Server 2016 introduced Temporal Database capabilities.
See:
The MSDN Documentation
This Channel 9 Video
The public preview (CTP2) announcment
When using SSIS in SQL Server 2005 to convert a FoxPro database to a SQL Server database, if the given FoxPro database has a date type, SSIS assumes it is an integer type. The only way to convert it to a dateTime type is to manually select this type. However, that is not practical to do for over 100 tables.
Thus, I have been using a workaround in which I use DTS on SQL Server 2000 which converts it to a smallDateTime, then make a backup, then a restore into SQL Server 2005.
This workaround is starting to be a little annoying.
So, my question is: Is there anyway to setup SSIS so that whenever it encounters a date type to automatically assume it should be converted to a dateTime in SQL Server and apply that rule across the board?
Update
To be specific, if I use the import/export wizard in SSIS, I get the following error:
Column information for the source and the destination data could not be retrieved, or the data types of source columns were not mapped correctly to those available on the destination provider.
Followed by a list of a given table's date columns.
If I manually set each one to a dateTime, it imports fine.
But I do not wish to do this for a hundred tables.
You could make a small FoxPro program that will loop through your list of tables and write out a SQL INSERT INTO statement for each record to a .sql file which you could then open from or paste into SQL Management Studio and execute. You could then control the date formats that will work with SQL Server's date type fields.
Something similar could be done in c#.