I have a few SQL Server tables with a datetime field that really only has to contain dates... and the fact that it's a datetime object violates data integrity, because it's possible for data to be inserted with a time - which isn't really valid for this field. The result is that we have to convert it and strip off the time every single time we use it. We've considered adding triggers to make sure that no data can even get in with a time attached... but it seems to me that this should really be part of the database software, and shouldn't need to be specifically programmed each time.
Why doesn't SQL Server have separate date and time data types? Is this going to change in the near future? Do other database platforms have this functionality?
SQL Server 2008 has DATE and TIME data types.
What version are you using?
SQL Server has a pure date and time data type since version 2008, they also added a bunch of new datetime types, now it also goes all the way back to year 1 instead of 1753
Related
We're migrating form SQL Server 2005 to 2014 for a pretty large environment. And we've noticed that OPENQUERY behaves differently when interacting with MySQL database when it comes to datetime. Previously, it would translate just fine to DATETIME column. With 2014 (I assume started in 2008 or so), it now converts to DATETIME2 (with maximum precision). This causes problems when comparing to or inserting into DATETIME columns.
Is there a way to specify on a server-level (or specify default) for which type those will translate to? Rewriting all of the queries will be quite an undertaking, and I'd like to avoid this now, if possible (rather rewrite as we edit or introduce new things).
Try to Use VARCHAR datatype while migration of date fields, and it is always easy to Convert/Cast in various types as per need.
I have an access database that we use for simple reporting solutions, this pulls data from a remote data base through an ODBC link. The data-warehouse provider has recently added a new data field to all of their tables which is formatted as a 'BIGINT'
Access now shows all records as deleted as it cannot deal with the BIGINT linked table.
As the data warehouse will not change their tables is there anyway that I can get the MS-Access to display correctly and ignore the 'BIGINT' field in the table linking?
I am having to work around this at this moment in time by copying the entire data warehouse minus this column to a MYSQL DB daily which is far from ideal...
I cannot for the life of me work this out.
Instead of using a linked table, just write a passthru query in Access. Eventually CONVERT your BigInt into a string or Integer, depending on the contents.
This link suggests loading the data into a local table with a data type of string:
http://social.msdn.microsoft.com/Forums/office/en-US/fb6f99ec-2ed7-487b-ba39-0777a0b44d5f/the-bigint-problem?forum=accessdev
Perhaps consider that MS Access's usefulness is limited here and it may pay to use SQL Server in future as you will continue to run into these kinds of problems. Is there any reason you can't use the datawarehouse directly?
You may also wish to consider using an .ADP (a file type of MS Access) which has a native OLE DB connection to the SQL Server database (no ODBC flimflammery) but also all the usual forms and reports.
ADP's are deprecated but I have had great success with them.
This is an old thread, but you can create a view and cast the bigint as int, and then Access will link to it.
Greg
This is an old thread but:
Casting your bigint as an int as someone has suggested isn't going to work if any of your values in your bigint column are bigger than the maximum value for an int (and if none of them are bigger than the max value for an int, it makes you wonder why a bigint is being used in the first place).
MS Access (from Access 2000 onward) does have a decimal data type, which is good for numbers of up to the maximum size of a SQL Server bigint and more. So if you make your MS Access field to be of type decimal, it can handle anything a SQL Server bigint can throw at it. In your process of taking the data from the SQL Server database into your MS Access database you would need something done programatically along the way to slurp your bigint values from SQL Server and squirt them into MS Access as decimal
I am using an Access form on the front end, bound to a SQL Server 2008 table. I have an Arrival Time column of datatype Time.
But I get an ODBC error every time I try to save a record. Error states:
Invalid character value for cast specification.
Time displays as 10:00:00 AM. I have tried with and without a time format in the properties of the field, and with/without an input mask of various types. Does anyone know how to avoid this error?
When I linked a 'Time' Field from SQL Server 2012 Express to an access front end (2010 accdb) using the old 'SQL Server' ODBC driver, it converted it to a Text field, and would not allow an updates. You might consider using a datetime field, or trying a newer ODBC driver. I believe the 'Time' field was first introduced in SQL 2008, so I'm guessing older ODBC drivers don't know how to handle it.
I've "inherited" a working Oracle (10g) to SQL Server 2005 data replication using standard SQL Server snapshot and transactional replication.
Everything works fine - as long as Oracle doesn't try to send a date that's outside the SQL Server DATETIME range (1753/1/1 to 9999/12/31). I was hoping to be able to somehow get in the middle of the data replication, check for that date range, and if necessary, tweak the Oracle date being published to be something that SQL Server 2005's DATETIME datatype can handle.
Is there any reasonably easy way to do this?? I know I could just change the target datatype to VARCHAR(19) or something like that - and I know I could upgrade to SQL Server 2008 and use the DATE or DATETIME2 datatypes to solve the issue - both options aren't viable right now (maybe in 6, 12 months or so).
Is there something I can do right now? And easily?? I cannot get too deep into Oracle to fix it here, unforutnately (that's another third-party company that doesn't like other folks fiddling around in their system).
I don't believe there's a solution to this - from what I understand, the replication process is similar to using the log reader for transactional replication, so it's a black box - it's unlikely that you could inject any code into the process, and if you could, it would be lower level code than SQL.
This is the second time it happens to me and before modifying a 3rd party Database structure I wanted to know if anyone knew a better solution:
I'm accessing a MS SQL Server 2008 from a Lotus Notes Agent (Notes 7) to retrieve some data. I use LSXODBC and my "Select" statement works perfect... Except that my agent cannot "understand" Nvarchar SQL Field types. Any other data types work ok (can get the values from number and dates fields without a problem).
It took me a while to figure it out, and I couldn't find a solution (other than modifying the field types on the SQL table to Varchar instead of nVarchar)
I could replicate this both in MS SQL 2005 and 2008.
Last "elegant" solution was to create an SQL view -instead of modifying table structure- with the varchar types instead of nvarchar. Works ok but I have to create a view for each table I'm retrieving data from.
I tried to set the Field type using FieldExpectedDataType Method but didn't work. Still got a DB_TYPE_UNDEFINED.
I thought there might be some configuration issues? or maybe I'm using an old LN Version / ODBC Driver version?
Any hint would be greatly appreciated.
Thank you in advance.
Diego
An old ODBC driver may not support unicode. It was not added until SQL Server 2000 (I'm fairly sure)