Date(only) and Time(only)

I was really expecting pure date and time datatypes to be in this CTP, but apparently there are not. It should be pretty simple to implement, given the fact that we already have the datetime datatype. However, it would save a lot of developers quite a bit of time. Are there any information why this isn't included? Is it planned for a later CTP?

[348 byte] By [OleKristianBangaas] at [2008-1-13]

«« Custom Field DataType Change and Warehouse Database Error
»» Cannot edit my public profile

# 1

It's planned for a later CTP. I was not ready in time for this CTP.

Thanks,

MarcelvanderHolst-MSFT at 2007-10-3 >

top of Msdn Tech,SQL Server Katmai,SQL Server Katmai Database Engine...

# 2

right along with this type of question - I could be mistaken, and correct me if I'm wrong, but my understanding was that the image and text LOBs were to be deprecated in SQL Server 2008?

Burkazoid2005 at 2007-10-3 >

# 3

Same here. But I do think they're still in so that they can run databases in SQL Server 2000 compatibility mode.

OleKristianBangaas at 2007-10-3 >

# 4

No, they were announced to be deprecated, but those announcements are always stating that it will be deprected in "the next versions of SQL Server"q. This version will not deprecate the types, but you should move to the other types as they will be "deprecated in the next versions" (might be the next after SQL Server 2008) :-)

Jens K. Suessmeyer.

http://www.sqlserver2008.de

JensK.Suessmeyer at 2007-10-3 >

# 5

Note that we announced the deprecation of IMAGE, TEXT and NTEXT already in SQL Server 2005. So please fire up your ALTER TABLE ALTER COLUMN and change them to VARBINARY(MAX), VARCHAR(MAX) and NVARCHAR(MAX), which is only a meta data change! And then get rid of your text pointer code ;-)...

Best regards

Michael

M.Rys[MSFT] at 2007-10-3 >

# 6

Beyond the fear of them being "removed in a future relase of SQL Server" (those types are prolific enough that I would figure you still have another release or two, but one can never say for sure), there are performance and code simplicity reasons to go ahead and get that migration done. Assuming you're utilizing the newer client libraries that are more aware of the (max) data types, treating them natively utilizing those forms instead of chunking and lob pointers is going to removing code that many of your developers may not fully grasp while improving performance.

In sure, while I'm usually not one for changing things for the sake of change - spending the time to get this migration done seems a relative no brainer to me as far as code updating efforts go.

RobertVieira at 2007-10-3 >

# 7

Absolutely agreed... there is no reason to keep TEXT/NTEXT around if you can change your code easily to use the MAX types.

aaronbertrand at 2007-10-3 >

# 8

aaronbertrand@discussions.microsoft.com wrote: > Absolutely agreed... there is no reason to keep TEXT/NTEXT around if you > can change your code easily to use the MAX types. (test)

MVPUser at 2007-10-3 >

# 9

Aaron Bertrand [SQL Server MVP] wrote: > aaronbertrand@discussions.microsoft.com wrote: > >> Absolutely agreed... there is no reason to keep TEXT/NTEXT around if >> you can change your code easily to use the MAX types. > > > (test) reference to undefined identifier: test [another test, in the form of a bad joke]

MVPUser at 2007-10-3 >

# 10

>> (test) > > reference to undefined identifier: test > > [another test, in the form of a bad joke] SELECT * FROM [Quiet, you!]; :-)

MVPUser at 2007-10-3 >

SQL Server Katmai

SQL Server Katmai Database Engine

SQL Server Katmai Hot Topic

SQL Server Katmai New Topic

How to find out what features are in this CTP release

SQL Server Katmai

Java / MSDN / Linux Tech / PHP Tech / MSDN DotNet / MSDN TECH / Health Library / Programmers Tech / visual basic Tech / Developer Tech / Ipod faqs / Msdn China Tech