Monthly Archives: June 2012

Correctly compare file date against TSQL stored date

If you need to track whether a particular file has changed or not (and I am not talking about FileSystemWatcher, often it’s an overkill), one way is to compare file’s LastWriteTime against stored value. But if you store the date value in SQL Server you may be in for a surprise – even if file date hasn’t changed – dates will not compare as equal. Consider following example:

'Reading current system file date/time
Dim dCurrentFileDate As DateTime = File.GetLastWriteTime(sFilePath)

'Storing file date/time in SQL Server table
CMyDatabaseClass.SaveDate(sFilePath, dCurrentFileDate)

'Immediately reading date/time value back
Dim dStoredFileDate As DateTime = CMyDatabaseClass.LoadDate(sFilePath)

'Comparing stored value against current
If dCurrentFileDate = dStoredFileDate
'
End If

The If statement on Line 11 will produce False results even if the dates seem identical. The reason – millisecond part of the datetime. SQL Server and .NET disagree on how to treat it so the best thing to do is to strip milliseconds from system file date/time before storing it or comparing against stored value.

Joe from StackOverflow.com offers a very elegant solution. That solution is in C# and here it is converted to VB.NET. To apply it to the example above simple add after the second line:

dCurrentFileDate = dCurrentFileDate.Value.AddTicks(-(dCurrentFileDate.Value.Ticks Mod TimeSpan.TicksPerSecond))

This will remove milliseconds from the date/time value and next time if you compare to the same value – values will be really equal.

Speed up Box.Net uploads

Box.Net service is know for its abysmal upload speeds, it’s a horrific sight to see your files crawl at several Kb/s, feels like blast from the dial-up past. But there’s a solution – instead of using official site – use it’s less known mirror: BoxEnterprise.Net

Box.Net fast upload

You can use it even if you have free personal account, for normal and bulk upload needs. Login and see your gigabytes fly by.

HTML Table RowSpan: Autofit spanned cells to content

Let’s say you have created an HTML table with following markup:

<table id="xMyTable" style="width:100%;">
   <tr >
      <td style="vertical-align:top">
         <div style="border: 2px solid black; background-color:red; height: 100px;">
         </div>
      </td>
      <td style="vertical-align:top" rowspan="3">
         <div style="border: 2px solid black; background-color:orange; height: 600px">
         </div>
      </td>
   </tr>
   <tr>
      <td style="vertical-align:top">
         <div style="border: 2px solid black; background-color:green; height: 100px">
         </div>
      </td>
   </tr>
   <tr>
      <td style="vertical-align:top">
         <div style="border: 2px solid black; background-color:blue; height: 100px">
         </div>
      </td>
   </tr>
</table>

It’s very basic, one rowspanned cell that holds a content with large height on the right and 3 corresponding cells with content of smaller height on the left. You’d expect it to look like this:

Desired layout of rowspanned HTML table

Unfortunately as is it works only in Google Chrome. In the rest of the browsers, including Interned Explorer and famed FireFox it looks like this:

Current layout of rowspanned HTML table

What happens is browsers automatically spread spanned cells height to evenly fit height of the cell with rowspan. To rectify this situation we need a little help from JavaScript. Continue reading →

Solution for “Operation is not valid due to the current state of the object” error

Typically this happens when AJAX controls are involved (Microsoft’s UpdatePanel or others that utilize AJAX POST requests.) The error may be displayed outright or, if nothing is shown on the UI – logged in the Event Viewer. In any case you will get a message similar to:

0x800a139e – Microsoft JScript runtime error: Sys.WebForms.PageRequestManagerServerErrorException: Operation is not valid due to the current state of the object

Issue happens because Microsoft Security Update MS11-100 limits number of keys in Forms collection during HTTP POST request. To alleviate this problem you need to increase that number.

This can be done in your application Web.Config in the <appSettings> section (create the section directly under <configuration> if it doesn’t exist). Add 2 lines similar to the lines below to the section:

<add key="aspnet:MaxHttpCollectionKeys" value="2000" /">
<add key="aspnet:MaxJsonDeserializerMembers" value="2000" /">

The above example set the limit to 2000 keys. This will lift the limitation and the error should go away.