This month’s (#127) T-SQL Tuesday is brought by B | T) and he asked about Non SQL Tips and tricks. As a Windows user I know there are lots of shortcuts and small hacks, that I love, which make my life much easier! Here is my small contribution: Windows tips & tricks and shortcuts WIN + X -> to access a lot of management stuff in a quick way WIN + V -> If you looking for a clipboard manager (keep multiple entries) since Windows 10 (build 1809) we can have it natively.
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. The oddity Few days ago I was talking with a friend that show me some “odd behavior” when working with dates on SQL Server.
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: So…what is happening? 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.
I’m converting some Firebird database code to T-SQL and I’m seeing a lot of code that doesn’t work in the same way that SQL Server. No surprise - I already expected that but for those that still say that “all engines/databases are equal”…“is SQL right?” here is another proof that is not true. On Firebird it is possible to use the CAST function using a DOMAIN (the equivalent in SQLServer is UDDT - User-Defined Data Types) as target data-type, well turns out that on SQL Server…that is not possible.
I’m currently working on a SQL code migration from Firebird to SQL Server and I hit an error that I haven’t seen for some time. The error message is the following: This ringed the bell right away! Somewhere on the code someone was trying to do an arithmetic calculation without using the proper function. How so? In the early days of my T-SQL coding, I used to do this a lot.
- OLDER POSTS
- page 1 of 2