Site sponsored by: Idera The gold standard of SQL Server performance monitoring & diagnostics.
SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • Quiz
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


Article Topics

All Articles
Performance Tuning
Audit
Business Intelligence
Clustering
Reporting Services
Developer
General DBA
ASP.NET / ADO.NET

Write for Us

Share your SQL Server knowledge with others and raise your profile in the community More...
Latest Articles

System Data Collection Reports
Recover Data Using Database Snapshots
Analyze and Fix Index Fragmentation in SQL Server 2008
Powerful Geographical Visualisations made easy with SQL 2008 Spatial (Part 2) ...

More     
 
Latest FAQ's

How to alter a User Defined Data Type?
How to unzip a File in SSIS?
How to view previous query plans?
ALTER TABLE SWITCH statement failed because the object '%.*ls' is not ...

More     
   
Latest Software Reviews

Spotlight on ApexSQL Doc 2008
ApexSQL Enforce
Embarcadero Change Manager
SQL Server DBA Dashboard

More     

articles >> developer >> Advanced SQL Server DATE and DATETIME Handling ...

Advanced SQL Server DATE and DATETIME Handling

By : Daniel Pfaff
May 25, 2004

There are lot of situations where you need an exact timestamp. For example, you may want to differentiate a recordsets’ creation dates, store technical measurements, or just to see how fast your latest SQL is running. Coding the 4th dimension is another common task, and therefore milliseconds are essential.

But there is a problem receiving milliseconds with ADO from SQL Server.

On one hand, VB with ADO, like this example:

Debug.Print cn.Execute("SELECT GetDate()").Fields(0)

returns:

23.07.2004 12:03:49

But on the other hand, running the same code directly in Query Analyzer returns:

23.07.2004 12:03:49.997

Even with:

Debug.Print FormatDateTime(cn.Execute("SELECT GetDate()").Fields(0), vbLongTime)

you won’t receive the milliseconds.

Okay, you can do a conversion to characters on the server and return that string like this:

Debug.Print FormatDateTime(cn.Execute("SELECT Convert(varchar, GetDate(),21)").Fields(0)

Which returns:

23.07.2004 12:14:07.993

But in my opinion, it’s to expensive to send such a long string over the net and store it in a much larger structure, than it could be possible in its native numeric form! There must be a way to handle milliseconds at the client.

Another problem is that SQL Server stores DATETIME with a precision of 3.33 milliseconds (0. 00333 seconds). This is not sufficient in some circumstances.

So let's take a look at what we can do.

 

The VB DATE & SQL Server DATETIME Datatypes

From the example above, it seems like ADO strips the milliseconds, but it really doesn’t, as I’ll show you later. First of all, you should understand how SQL Server’s DATETIME and VB’s DATE represent their data.

Both use 8 bytes to store the data, where the first 4 bytes are the date and the last 4 bytes represent the time.

The data type DOUBLE can store 8 bytes too, which means you can transform DATETIME to DOUBLE with no loss of information!

And last, you should always remember:

  • SQL Server only stores dates from: 01.01.1753 to 31.12.9999
  • VB’s date range runs from: 01.01.0100 to 31.12.9999

So you can always convert SQL Server dates to VB, but the other direction won’t work with historical dates. The conclusion is that you can handle both dates later than 01.01.1753.

 

The Lost Milliseconds

So why does VB strip the milliseconds? The answer: It doesn’t!

VB’s standard for date/time operations is based on seconds, as it’s minimal unit. (E.g. the Now() function returns the current system time and rounds its milliseconds.) Consequently, FormatDateTime and other date/time function do the same. They are built for VB and ‘exotic’ values from outside its world are treated fine, by rounding them.

If you want to measure milliseconds in VB you can use the Timer() Function on the Windows OS, but this won’t work with the MAC OS (MAC just returns full seconds). Timer() returns the seconds after midnight as single data type and the fractional part will contain the milliseconds! We’ll use this function in the later section, “check your SQL!”

 

Receiving Milliseconds from SQL Server with ADO

As I previously explained, VB naturally doesn’t expect milliseconds. For this reason you have to write a small function, to teach it how to understand them.

Before you start, you should realize there are 86400 seconds per day (86400s/d = 24 h/d * 60 min/h * 60 s/min). The following function will strip the milliseconds from the SQL DATETIME and format the entire date expression:

'returns the fractional part of a positive double
'in VB.Net you can substituted this with the truncate function
Function Frac(dbl As Double) As Double
Frac = dbl - Fix(dbl)
End Function

'returns a formatted date with milliseconds
Function FormatDt(ByVal dt As Double, Optional strFormat As String = "yyyy-mm-dd hh:mm:ss") As String
Dim dblMSec As Double
' strip the full seconds of the day from dt, to return the percentage of the seconds left.
dblMSec = Frac(86400 * dt)
' remove the milliseconds from dt, so that format won't round it (because it's 0)
dt = dt - (dblMSec / 86400)
'return the formatted dt.
FormatDt = Format(dt, strFormat) & Format(dblMSec * 1000, "\.000")
End Function


The following function will test this approach:

Sub TestFormatDate()
Dim cmd As New ADODB.Command, rst As New ADODB.Recordset
'init command to get the date and it's string equivalent, to compare them later
With cmd
.ActiveConnection = "Your connection string here"
.CommandText = "SELECT GetDate(), Convert(varchar,getdate(),21)"
.CommandType = adCmdText
End With
rst.Open cmd

'show results and compare the values
MsgBox "Server: " & rst(1).Value & vbCrLf & "Daniel: " & FormatDt(rst(0).Value)

rst.Close: Set rst = Nothing: Set cmd = Nothing
End Sub


    Next Page>>    








Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | QDPMA Performance Tuning | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views


              © 1999-2008 by T10 Media. All rights reserved