Static Code Analyzer for T-SQL – MS SQL Server.

Static Code Analyzer for T-SQL – MS SQL Server.
Plugs into MS SSMS and can also be run from command line.

It reports useful clues which you can turn/on off to your liking. 
http://sqlcodeguard.com/index-database-issues.html

It will spot declared but unused variables, but it appears it doesn’t do code coverage or execution path to spot stuff like variables being used without being initialized.

http://sqlcodeguard.com/

Price: Free

#sql   #analysis  

http://sqlcodeguard.com

Zero to Hero with Microsoft SQL Server 2014 Database

Zero to Hero with Microsoft SQL Server 2014 Database

If you are new to SQL databases, this 5 hour(!) video starts with the absolute basics, and progresses into fairly advanced use, tuning and debugging.  Some of it is specific to MSSQL Server, but the basics are conceptually applicable to most SQL dbs.

http://goo.gl/NaHkPa

Any users of FireDAC TFDScript out there?

Any users of FireDAC TFDScript out there?

Scripts produced by ApexSQL Diff, which runs fine in SQL Server Management Studio, fail when run from a TFDScript.  I am trying to figure out if it is options related, or if it is an implementation problem.

Problem 1: Transaction handing causes an error:  

Exception class EMSSQLNativeException with message ‘[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL Server]A transaction that was started in a MARS batch is still active at the end of the batch. The transaction is rolled back.’. 

Problem 2: If I remove the begin tran at line 38/39 and reduce the script to only contain the create table part – it still fails silently. The spool output shows no errors, nor does any errors show in the FireDAC Monitor.  And yet – no table is created.

I also suspect that multiline /* block comments */ confuse the script analyzer.

Suggestions, anyone, particularly for Problem 2?

#firedac   #script  

http://pastebin.com/dzR8T6fC

FireDAC Date Handling – FireDAC Date Mystery Part II

FireDAC Date Handling – FireDAC Date Mystery Part II

As it turns out, the mystery was not fully solved.

After adding map rules (see old post) to FireDAC for how to handle dtTime and dtDate, I removed the old ADO special case handling and just did

Result := FieldByName(FieldName).AsDateTime;

Which worked well – or – so I thought.  I had done all my testing on machines that had the SQL Server Native Client installed, and it showed no problems.

But – when I ran on a machine without SQLNCLI installed, the date format issue reared it’s ugly head again.

So – this is the “final” workaround which so far appears to handle every date/time format that I have tossed at it.

function TPSDRecordset.GetAsDateTime(const FieldName: string): TDateTime;

var

  F: TField;

  s: String;

begin

    F := FieldByName(FieldName);

    try

    case F.DataType of

      ftDateTime: Result := F.AsDateTime;

      ftTime: Result := StrToTime(F.AsString);

      ftDate: Result := StrToDate(F.AsString);

      else begin

        OutputDebugString(‘GetAsDateTime(‘+FieldName+’).DataType=’ + IntToStr(Ord(F.DataType)));

        Result := StrToDateTime(F.AsString);

      end;

    end;

  except

    on E:Exception

    do begin

      s := FieldByName(FieldName).AsString;

      OutputDebugString(Self.ClassName + ‘.GetAsDateTime(‘ + FieldName + ‘) = ‘ + s + ‘: ‘ + E.ClassName +’ – ‘ + E.Message);

     raise;

    end;

end;

#FireDAC   #SQLServer   #NativeClient  

Originally shared by Lars Fosdal

A FireDAC Date Mystery

I have an app that connects to a MSSQL db through FireDAC and retrives a selection of log data, including the date and time of the logging in a datetime field.

I leave the app open for a longer period of time (about an hour, I think), then I refresh the view.

BAM! The dates show up as 1899.  For some reason, FireDAC has decided to forget how to get the datetime in the right format.

I suspect that is is related to a connection object that has lost it’s connection, but why can it reconnect and get data, and yet get the date format wrong?

#FireDAC  

A FireDAC Date Mystery

A FireDAC Date Mystery

I have an app that connects to a MSSQL db through FireDAC and retrives a selection of log data, including the date and time of the logging in a datetime field.

I leave the app open for a longer period of time (about an hour, I think), then I refresh the view.

BAM! The dates show up as 1899.  For some reason, FireDAC has decided to forget how to get the datetime in the right format.

I suspect that is is related to a connection object that has lost it’s connection, but why can it reconnect and get data, and yet get the date format wrong?

#FireDAC