I have a SQL Server 2012 table with a column named X and defined as DATE.
When I run GetOleDbSchemaTable(OleDbSchemaGuid.Columns,...) the DATE_TYPE comes up as 130. I was expecting 133.
Can anyone please explain? Many thanks!
From MSDN Using Date and Time Data:
Backward Compatibility for Down-level Clients
Some down-level clients do not support the time, date, datetime2 and
datetimeoffset data types added in SQL Server 2008. The following
table shows the type mapping between an up-level instance of SQL
Server 2008 and down-level clients.
You see the 130 because of backwards copatibility
Related
I have a program in C# which connects to a database using a DSN (ODBC driver).
All queries I run in the program uses SQL. All works well but when using datetime data type in queries (in SELECT statement or in WHERE clause).
When DSN is a MS ACCESS database, I have to use something like this:
WHERE SomeDate = #1/1/2005#
But if the same database is in SQL Server, i should use something like this:
WHERE SomeDate = '1/1/2005'
Is there a way to manage this in the same program without doing a routine for SQL Server and another for MS ACCESS?
I tried by getting properties of OdbcConnection object, but I could not find a way to detect if driver is MS Access or SQL Server.
You probably have used data type Datetime2 in SQL Server. That will be read as text if using the native SQL Server ODBC driver.
So either:
Use the Microsoft® ODBC Driver 11 for SQL Server® - or newer, 17 is current:
Microsoft® ODBC Driver 17 for SQL Server®
Change the data type of the field to DateTime
You can set your Access database to be in ANSI-92 mode. This will allow you to query date fields with single quotes.
A word of warning though if this is an existing database or there are other applications using it. This may introduce a breaking change to any existing queries in your database that are not ANSI compliant. Likewise, if there are other applications using this database their queries may also break.
Also as an alternative, please note that OdbcConnection does have a Driver property that you can probe to determine the data source. On my machine, a DSN pointing to a SQL Server database returns sqlncli11.dll, because I am using the SQL Server Native Client 11.0. You can use this property to drive the syntax of your queries in your application. You could create a data access layer that abstracts some of this away from the rest of your code.
SQL Server 2008 R2 supports CLR integration where a .NET module can be registered in the database and can be invoked through SQL stored procedures, functions, triggers. We are able to develop such .NET modules and integrate with SQL Server.
But we have a different requirement where it is required to intercept the SELECT queries send to SQL Server (from any SQL client) and invoke a .NET module and pass the query parameters (WHERE clause) to it.
For example if we have a table (VarInfo) in database having two columns VarID (string) and Value (float). Now suppose the table contains records for 100 variables with VarID: V001 to V100. But the Value column is empty for all records. The Value data is not stored in the database. If we have a SQL select query:
SELECT Value from VarInfo where VarID = 'V001'
then the SQL Server should invoke the .NET module and pass the VarID. The .NET module shall fetch the variable Value from some external source. It shall then return the Value back to SQL Server. The SQL Server should return that Value as query output/result.
Please let know about the feasibility of the above in SQL Server 2008 R2.
Thanks,
The closest you could get would be a CLR User-Defined Function - but the calling code needs to be aware that it's a UDF and pass the parameters slightly differently, like:
SELECT Value FROM dbo.CLRUDF('V001')
I'm using Entity Framework 4 with an MVC3 application to access data.
My SQL server version is SQL Server 2005.
When trying to save data, I get this error:
The SQL version used is not compatible with data type 'datetime2'.
Can someone explain what this bug is and how to fix it?
I never declared a property to be of type datetime2 and in act I never even heard of this data type before today.
After some Googling around I found somewhere that suggested I change the token of my .edmx file to use 2005:
<Schema ... ProviderManifestToken="2005" ...>
Yet this error is still firing.
Any suggestions?
DateTime2 is only available on SqlServer 2008 or later
DATETIME2 is introduced in SQL Server 2008
You can change what you want on your "client" application, if the server does not supported it will not work.
I have a basic/simple need to create a pipeline transfer process from one SQL express 2008 database to another server (equally SQL 2008 express).
Basically:
I have one table on SERVER A which has data coming in, and a default field called 'downloaded' which is again, by default set to 'N'
I have the same table schema on SERVER B
On a timed basis (say every 10 mins), I need to get all records from SERVER A where the 'downloaded' field is set to 'N', and copy that whole record to SERVER B
As each record from SERVER A is read/successfully copied to SERVER B, I set the 'downloaded' flag to 'Y' (with a timestamp field too).
From old memories, I used DTS (now SSIS I guess) to do something similar.. but of course SQL express doesn't have the loveliness!!
Question:
Is it just a case of a SQL datareader to get data from SERVER A and manually either INSERT a SQL statement to SERVER B (or a proc of course)?? any other slick ways?
Thanks for all comments...
oh don't use flags! They are not good for indexing.
Add two columns to both source and target tables:
dt_created
dt_modified.
Add an index on each one.
From your target database, select the source database/table for dt_created > max(target table.dt_created). Those are your new records.
Do the same for dt_modified, and those will be your modified records. See! Poor man's replication.
Well, how about MySQL with replication? Cheap and slick :-)
But I afrait it's too late to change DB...
This has got me really flumoxed!
In the datalayer ADO.NET connects to SQL Server 2008, Default language for the login is 'british'
Selects a DateTime column into a dataview and returns it.
aspx page databinds
this: <%# String.Format("{0:MMM/yyyy}", Eval("dbPeriodFrom")) %>
The database returns 2009/10/01 (This is yyyy/MM/dd)
The result of step 4 is Jan2009 ????
The regional settings of the web server is United Kingdom
There is no <globalization... section in machine.config
The NET globalisation in IIS is set to uiCulture=en culture=en-GB
I even set it in the web.config for the site
This is a classic "Works on my dev machine.." But, borked when deployed to production scenario.
What could I possibly have missed?
EDIT
So it appears the login used by the ASP.NET Application to connect to SQl Server 2008 is getting a US datetime, even though in the properties for the login, the default language is set to 'British English'.
The problem occurs in TSQL:
SELECT
DATEPART(month, CAST('2009.02.01' AS DATETIME))
,DATEPART(month, CONVERT(DATETIME, '2009.02.01', 102))
OUTPUT for windows integrated login (Administrator) with default language set to 'English'
2 2
OUTPUT for SQL Server login used by ASP.NET with default language set to 'British English'
1 2
Check the locale setting on the database itself and on their server, depending on the set up, the date will be formatted accordingly to the locale setting. I suspect the database server is probably set up to US English - Poke around in the regional settings on the db server itself.
Hope this helps,
Best regards,
Tom.
I'd be interested in seeing the code where you get the date out of the command/reader/adapter - if the database column is typed as a datetime, then what comes over the wire isn't actually "2009/10/01" - it is a binary number (like most dates are on the wire). As such there is no ambiguity.
I expect that somewhere you are treating it as a string (perhaps some Parse) - this shouldn't be necessary. If it is, you aren't SELECTing it as a datetime, but as a [n][var]char(x).
Check value stored in database using Management Studio. Also in MS SQL server universal format of date is YYYY-MM-DDTHH:MM:SS.mmm (2009-01-05T10:12:55.001) and YYYYMMDD (20090105). Those formats parsed always the same, no matter which locale used by database.