On 29th September we will have SQL Saturday Porto and I’m proud to announce that I will be speaking!
I will be speaking about dbachecks PowerShell module - dbachecks - Checking SQL Server environments with PowerShell .
The event will be held at ISEP, Rua Dr. António Bernardino de Almeida, 431, 4249-015 Porto, Portugal and you can see the full schedule here .
Register , it’s free!
Almost all the applications we use have a lot of options. And, sometimes we even stumble across them by accident. Who’s ever heard something like “Normal user don’t even use 5% of Excel capabilities!”?
Other options, we know they exist but because the default value it’s ok (so far) we tend to forget it. It is just sitting there, waiting for the day we want/need to change it.
Few days ago I was talking with a friend that show me some “odd behavior” when working with dates on SQL Server.
I’m working on a project where I need to convert Firebird SQL code into T-SQL code. No schema, just the modules. There are more than 1000 objects between stored procedures, views, triggers, user-defined data types, etc.
While checking the Firebird reference manuals I saw a lot of different concepts (Selectable Stored Procedures - Yes you can do SELECT FROM StoredProcedure) and different functions names with different syntax compared to T-SQL.
Starting on 19th of July and during 3 days the Tuga IT 2018 Summer Edition will be happening in Lisbon!
This edition will have:
4 full-day workshops 38 breakout sessions (1 hour) 5 deep dive sessions (2 hours) That is over 72 hours of content delivered by 44 awesome speakers, many of them recognized industry experts.
You can see the full schedule here . This edition will have sessions about: Cloud, Data Platform, Development, Integration, IOT, Office, PowerShell and Security.
If you have been reading my last blog posts, you know that I’m currently working on a SQL code migration from Firebird to SQL Server.
The client provided the scripts with all modules (Stored Procedures, functions, etc) and the steps I’m following (roughly speaking) for converting are:
The file that is used to create a new query window has ANSI encoding but when I save the file on the PowerShell script I save it as UTF-8 because the client have comments on the code with unicode characters.