I was reading a post that had this quote: " The MongoDB docs tell you what it’s good at, without emphasizing what it’s not good at. "
This isn't to pick on MongoDB, but the post did make me wonder what things SQL Server isn't good at? Should our docs, BOL specifically, have warnings about scenarios where there might be problems with code? In addition to the remarks section, should there be "Warnings" section about various features, functions and code? I image that the CREATE FUNCTION page might have some warning about scalar UDF performance in many situations, and I'm sure many of you would think of warnings that might be added for other features.
I understand Microsoft might not like to point out flaws, but in the interest of building better code and applications, shouldn't various versions of BOL, and perhaps all docs, warn the client about potential issues with using a feature in a certain way? Documenting the potential problems with using a feature in particular situations isn't a flaw; it's guidance about how misuse might introduce other issues.
It's not likely that we'll start seeing more warnings in the official documentation, but for those of you that would like to improve the situation for others, there are always the "Community Additions" sections on all BOL pages. I don't know if Microsoft would post your warnings there, but if they allow them, we might be able to help others understand the pitfalls of using a particular technique.
In this series on implementing data services in Azure, Marcin Policht turns his attention to the remediation of incompatibilities resulting from of limitations inherent to Platform as a Service (PaaS) based deployments, which will need to be addressed as part of the migration process. More »
Question of the Day
Today's Question (by Steve Jones):
Which of these wildcard characters is used to match a single character? (Select 2)
Think you know the answer? Click here, and find out if you are right.
We keep track of your score to give you bragging rights against your peers.
This question is worth
1 point in this category: T-SQL.
We'd love to give you credit for your own question and answer.
To submit a QOTD, simply log in to the
Expert Performance Indexing for SQL Server 2012
Expert Performance Indexing for SQL Server 2012 is a deep dive into perhaps the single-most important facet of good performance: indexes, and how to best use them. The book begins in the shallow waters with explanations of the types of indexes and how they are stored in databases. Moving deeper into the topic, and further into the book, you will look at the statistics that are accumulated both by indexes and on indexes. All of this will help you progress towards properly achieving your database performance goals.
IN BIDS (SQL Server 2008 R2), which one of the following returns the system's container start time in either of the following formats? Please keep in mind you are using this variable in email messages.
(DT_WSTR, 60) @[System::ContainerStartTime]
(DT_STR, 60, 1252) @[System::ContainerStartTime]
(DT_WSTR, 60)(DT_DATE) @[System::ContainerStartTime] (the use of DT_DATE is redundant since the variable is already a DateTime)
To begin, I gave two optional DT formats. I have used both by configuring SSIS (and\or my system's DT) to be able to display both formats.
ContainerStartTime is a system variable (the Container's Start Time) that is made up of Date and Time and it's default type is DateTime. An example of using this is in an "OnError" event where you want to send an email message containing the Date and Time of the error. Since the MessageSource (an expression in the Send Mail Task) is string based, you have to convert the datetime system variable to string (known as Type Casting).
If you were to use the SSIS function "GetDate()," the date time function will return in the format DT_DBTIMESTAMP with a higher precision for the fractional seconds. This function returns the system's date and time (29 character return).
As for the other options,
(DT_DATE) @[System::ContainerStartTime] produces type cast error.
(DT_WSTR, 60)(DT_DBTIMESTAMP2, 4) produces a different format other than the one indicated in the question (plus adds precision to the time (fractional seconds))
(DT_TEXT) @[System::ContainerStartTime] produces a type cast error.
(DT_STR,50,1252) (DT_DBTIME2, 7) @[System::ContainerStartTime] only returns time (with precision (fractional seconds))
Function has two input parameters; a string and delimiter.
Parameter string will be used in function for:
1) to split the values
2) add any additional logic as denoted in part with
/* --- COPY/PAST YOUR CASE STATEMENT --- */
3) concatenating new values back to string
4) returning string.
Parameter delimiter is simply a char, used in function to destinguish how to split a string.
E.g.: '1,3,5,7,2,1' uses comma for delimitation between the values.
Alter function and taylor it to your needs in section marked with START and END. It uses CASE statement, but can easly be replaced with any other statement. Also joins can be added for bounding on to your data.
Usage for function is as following:
DECLARE @myString VARCHAR(10) = '1,1,2,2,42'
DECLARE @delimiter CHAR(1) = ','
@myString AS inputString
,[dbo].[Split_and_concatenate](@myString, @delimiter) AS outputString
Copy-only backups and differentials
- Please consider the following scenario:
Day1: FULL DB Backup
Day2: Differential Backup
Day3: Copy-Only Full Backup
Day4: Differential Backup
am I right in thinking that...
Difference between dates
I have the following data in a table :
EmpNo BudgetYearStart BudgetYearEnd
2698 2013-02-01 2014-01-31
67682 2013-01-01 2013-12-31
43320 2013-02-01 2014-01-31
2849 2013-03-01 2014-02-28
67687 2013-01-01 2013-12-31
67675 2013-01-01 2013-12-31
67678 2013-01-01 2013-12-31
SQL Server 2008 Evaluation
- Can I use now SQL Server 2008 Evaluation in production environment? Or should I use only 2012?
SQL Query help
1. First Query Gives me Outstanding Amount for Billing. Here Transaction type is ('SLINV','SLCRD')
SUM((SL.BASEVALUE)*CASE WHEN CURR.RATE IS NULL THEN...
This newsletter was sent to you because you signed up at SQLServerCentral.com.
Feel free to forward this to any colleagues that you think might be interested.
If you have received this email from a colleague, you can register to receive it here.