January 26, 2013 at 2:47 am
Comments posted to this topic are about the item Not Pulling the Plug Out
Best wishes,
Phil Factor
January 26, 2013 at 3:15 am
Phil -
In most instances, I agree with your observations regarding the SQL Server folks.
However, there is one glaring and monumental foul-up that has me wondering if that group's long-standing customer focus in on the way out.
I am referring to the violation of the most elementary product program "don't" of not leaving your base high and dry with no way to migrate to a new release. This of course refers to the recent posts stating that SSDT 2012 will not support the migration of older SSRS project files.
It is inexcusable that Microsoft would not consider it necessary to provide a means of migrating (in my case 100s) of SSRS project files forward to the newer SSDT.
It makes me wonder if the people in the product management chain have taken leave of their senses. Do they understand anything at all about the real world of their customers?
I have seen a post on an msdn forum that would seem to indicate a distinct lack of cooperation exists between the BIDS team and the Visual Studio Team, the thread would seem to indicate that a BIDS 2012 may be forthcoming, but that the VS team has no intention of providing backward compatibility for older SSRS project files in SSDT.
Were it in my power to make an executive decision at MSFT in the wake of this fiasco it would be that from here on out the VS team is not authorized to release product with the SQL Server brand. THE BIDS team would have sole control over the development studio feature and function set for SQL Server. The VS team has shown a profound lack of understanding of the customer in this one.
Unfortunately, I do not have the decision making authority in my new position as regards a migration to SQL Server 2012. If I did, we would not go forward on SQL Server 2012 until the powers at MSFT remedied this train wreck. Someone in the VS product management chain should lose their decision making authority over this one!
January 26, 2013 at 5:18 am
I have to agree that anything to do with SQL Server is entirely unsafe in the hands of the VS team, considering that the culture there is so foreign to the way that we do things.
When I gave praise, it was for the SQL Server team, not those VS kids and their doo-lally disconnected model of database development. As if developing databases wasn't hard enough already.
Since I read Robert Sheldon's series on Report Builder 3, http://www.simple-talk.com/author/robert-sheldon/%5B/url%5D I've been using that for reports in SQL Server 2012.
Best wishes,
Phil Factor
January 26, 2013 at 7:38 pm
The one question is did they restore the "BACKUP Log With TRUNCATE_ONLY" option?
I have been in so many situations that I walk in after a bulk data load or a replication failure and the system is down because the tran log is full and there is no space on disk. There is no way to get the system up while you troubleshoot the problem.
I have had to try to add an additional log file with no disk space on the original file to accept the command because the first tran file is full.
Then the argument is why are you in full recovery? Because I need a general Piont-In-Time recovery option. The fact that the SQL Server agent failed is not the cause that the backups didn't get done. It is the incompetent DBA that didn't choose the right backup model.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 26, 2013 at 8:01 pm
Jim P. (1/26/2013)
It is the incompetent DBA that...
Let's put some quality back in the title of "DBA". Whether they have the actual title or not, there are actually no incompetent DBAs... if someone is incompetent, they can't actually be a DBA even if they have the title. 😉
In the case you cited above, it should be changed to "It is the incompetent dumb a55 that currently holds the DBA position that..." 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2013 at 8:04 pm
Phil Factor (1/26/2013)
I have to agree that anything to do with SQL Server is entirely unsafe in the hands of the VS team, considering that the culture there is so foreign to the way that we do things.When I gave praise, it was for the SQL Server team, not those VS kids and their doo-lally disconnected model of database development. As if developing databases wasn't hard enough already.
Since I read Robert Sheldon's series on Report Builder 3, http://www.simple-talk.com/author/robert-sheldon/%5B/url%5D I've been using that for reports in SQL Server 2012.
I would love to get my hands on the persons that wrote the code that generates tables from VS. It would result in server cases of pork chop poisoning and sudden impact syndrome. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2013 at 8:51 pm
Jeff Moden (1/26/2013)
In the case you cited above, it should be changed to "It is the incompetent dumb a55 that currently holds the DBA position that..." 😀
I know you are trying to be facetious. But I consider myself a competent DBA. That I don't put a DB into the simple recovery model for the first couple of days of a month means I'm incompetent?
I've had to deal with it all. I don't want the end user catching on that something is wrong. And it is not the fault of the DBA that the developer is insisting on using replication and dreams it is perfect. I have had to figure out what dropped in replication and delete the individual transaction, in a 12 minute situation.
Please tell me that it is my fault that M$ and Oracle and the rest of the systems are not perfect.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 27, 2013 at 8:46 pm
Phil:
Well stated. Let me add that I too deeply appreciate the loyalty of the SQL Server creation team at MS. They are the exception who ideally will continue when the rest of MS is wearing pink underwear and tacky dark mascarra in homage to the metro vision of south park.
It is so very, very sad to watch a once great company die the death of bureacracy choke.
January 28, 2013 at 5:51 am
I'll echo jvolters sentiment on a separate part of the VS integration. Our team uses Rapid App. Dev. and we push out individual changes constantly, so in order to deploy changes to our source-controlled stored procedures, we often make the change right in Visual Studio, run against test, then run against staging, and if all went well, we then run against production, all within Visual Studio 2008. Since 08 can't connect to our new SQL '12 I tried both SSDT 2010 and SSDT 2012, and in both cases, there is no option to be prompted for a connection. You have to set the connection in Tools->Options, and then if you want to connect to a different database, you have to go back to Tools->Options and change the "default" connection. This is very cumbersome and as soon as this became apparent, our developers started applying changes via SSMS and now don't check in their changes to source control. This is just a complete mess and if we had known this would be such a problem, we would not have upgraded to SQL 12 at all. You may say that well, that's the VS team, but if the two teams aren't on the same page and playing nicely together, one will suffer for the other's incompetence.
-VG
January 28, 2013 at 6:24 am
It's not just the VS team not playing nice with the SQL team. As a developer/analyst/admin, I have to deal with that and the "fonts and colors" team screwing with the desktop (Windows 8 and Metro), the big push of Azure and it's under developed tools, etc... :crazy:
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply