I am working on a business case for using SQL Server CE for the upcoming project and I have a hard time convincing the upper management to go with this database solution. Their impression is that SQL Server CE will not be supported by Microsoft in the future. During my research, I have not found any evidence for this but I also have not found any official roadmap that indicates otherwise. Does anyone know any good references that I could use in my business case? I have also emailed the CE team with the same question, but I have not heard back from them yet.
Thank you in advance.
I can't find a support lifecycle for the recently released SQL Server CE 4, but the previous version 3.5 will be supported until 2013:
Microsoft Product Lifecycle Search
Products Released | General Availability Date | Mainstream Support End Date
SQL Server Compact 3.5 | 19/02/2008 | 09/04/2013
so chances are the new build will be supported for about five years too - or longer if it gets bundled with the next version of Visual Studio as it'll likely pick up the VS support lifetime. Their general Business and Developer products support policy is
Microsoft will offer a minimum of 10 years of support for Business and Developer products. Mainstream Support for Business and Developer products will be provided for 5 years or for 2 years after the successor product (N+1) is released, whichever is longer. Microsoft will also provide Extended Support for the 5 years following Mainstream support or for 2 years after the second successor product (N+2) is released, whichever is longer. Finally, most Business and Developer products will receive at least 10 years of online self-help support.
Related
Looking for a straight forward answer from the SQL guru's
To make a decision on which license to purchase, we were looking for the number of databases supported by a server instance of each edition (Express, Web, Standard, Enterprise) but couldn't find any useful information on the net. Any help is appreciated.
Technical answer: 32,767
Practical answer: much harder and more variables
There is no difference between editions, but performance features as the editions go up can enable your machine to practically support more dbs.
Source: https://msdn.microsoft.com/en-us/ms143432.aspx
there are four editions mainly (Express, Web, Standard, Enterprise),it support upto 524PB size except express edition(which is support 10GB).first create one database and see the size of that based on that calculate the no.of databases that particular edition support it.:)
for more:https://msdn.microsoft.com/en-us/ms143432.aspx
I am planning to upsize an Access 2010 database to a SQL Server version 11 (these are the versions I use in the moment).
I am familiar with Access since version 1.0 and, to a lesser extent, with SQL-Server since a couple of years. But the last time I upsized an Access database to SQL Server was many years ago.
Now I am studying articles on the internet about the automatic and manual upsizing. But almost all of these articles relate to Access versions 2003 or 2007 and earlier SQL Server versions.
Now my question: Did anything significant change about the upsizing process over the last years and versions or is it basically still the same process? Did certain things change so much that a recommendation i.e. for Access 2007 is irrelevant or maybe even wrong for 2010?
One example is this article which “Applies To: Access 2007”:
Move Access data to a SQL Server database by using the Upsizing Wizard
https://support.office.com/en-us/article/Move-Access-data-to-a-SQL-Server-database-by-using-the-Upsizing-Wizard-5D74C0DF-C8CD-4867-8D07-E6E759D72924
Or this article from year 2000:
ACCESS DATABASES ( DSN vs DSN-LESS)
http://www.powerasp.net/content/database/dsn_vs_dnsless.asp
I am willing to read and learn but obviously I don’t want to waste my time reading staff which is outdated and now maybe wrong.
How is your experience with upsizing a new version of Access compared to an older version? Did something significant change?
The Version of Microsoft SQL Server is negligible regarding your Question.
There are two important changes in the history of Access regarding SQL-Server-Backends.
1.) With Access 2000 Microsoft introduced the new ADP (Access Data Project) file type that allows closer integration of MS-SQL-Server-Databases as Backend using ADO (ActiveX Data Objects). This was the recommend way to build Access applications with SQL-Backend for a couple of years.
However, after the release of Access 2010 Microsoft decided that they are not going to support the ADP-File-Type anymore and they removed all support for ADPs in Access 2013!
2.) Up until Access 2003 the DAO-Library (Data Access Objects) included support for ODBC-Direct-Workspaces, which allowed you to call stored procedures and functions on SQL-Server via DAO. But with Access 2007 Microsoft removed ODBC-Direct and hinted towards the ADO and ADP-Features to implement such stuff in your application. – When they later (Access 2013) changed their recommendation to use DAO instead of ADO/ADP for SQL-Connectivity, they did not provide any useful replacement for ODBC-Direct.
The current recommendation (by Microsoft) is to use Access with the DAO-Library and linked tables via ODBC to connect your Access-Frontend-Application to SQL-Server. Pass-Through-Queries are recommended for anything that is beyond a linked table or linked view.
I personally advise to extend this approach by combining DAO/linked-tables with an ADO-Connection to SQL-Sever in VBA to call Stored Procedures and Functions on SQL-Server, instead of Pass-Through-Queries. This obviously creates a bit of a technology mix-up but it tremendously increases your possibilities to interact with business logic implemented in the SQL-Server-Database.
If you keep all that in mind, most of the advice regarding Access-SQL-Server-Upsizing is still valid, no matter how old it is.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Our 5 developer MSDN license is about to expire. We are using TFS 2012. Do we really need to renew the license so that we keep using the TFS 2012 server?
I always thought the MSDN licenses were perpetual licenses. Meaning you keep using whatever software you have downloaded and installed after the MSDN license has expired. Recently, I tried searching for the word perpetual in the license agreement but it seems that Microsoft has removed the word.
I have talked to the resellers and they are saying that I need to buy the MSDN subscription but to be honest salespeople are always trying to sell you stuff even if you don't need it.
Can anyone shed more light on the subject please?
MSDN licenses are as far as I know limited to the term of the license. Think of them as a rental of software for the duration of the license. When it expires, they want their software back, just like a rental car agency.
If you are trying to keep your costs down, you may want to look at the following options to stay in compliance:
Microsoft Visual Studio Online, formerly TFS Online (https://www.visualstudio.com/en-us/products/visual-studio-online-pricing-vs.aspx)
5 free users
VS Community Edition for free
VS Professional available for $45/month per user
Microsoft Action Pack Subscription (https://mspartner.microsoft.com/en/us/Pages/Membership/action-pack.aspx)
$475 / year
Provides software for up to 10 users
Provides limited MSDN licenses for 3 developers, including VS2013 Professional
I think it is latest version of software only which is why I am putting limited.
Azure Credits
Lots of other benefits: https://mspartner.microsoft.com/en/us/pages/membership/action-pack-application-design-development.aspx#Market
So while I can understand the sticker shock of renewals (I feel them every year myself), using a few of Microsoft's programs for small businesses (if you qualify) sure makes it easier on the bank account.
From this link:
Microsoft licenses TFS under the Server/Client Access License (CAL) licensing model. You must have a license for each running instance of TFS and, with certain exceptions, a TFS CAL for each user or device that accesses it.
So you definitely need a subscription for a running TFS instance, however 5 MSDN accounts may not be needed. You do however get TFS with your MSDN subscription:
Eligible MSDN subscribers receive TFS and a TFS CAL as part of their subscription benefits.
In any case, read more about CAL here. And contact MS directly to get a license that best fits your needs.
I'm starting a new project and I'm considering using sqlserver 2008.
I've had a lot of trouble getting teamsystem to work with it, and I'm wondering if sql server 2008 is widely used in productions environment yet.
What whould you choose? How do you compare sqlserver 2005 and 2008?
EDIT : I agree about the obvious and general tradeoff between new (new features, one painfull migration avoided in the future) and old (less bugs, more documentation). I've already browse the web about differences between 2005 and 2008. My question is more specific : Are YOU using 2008? are YOU experiencing problems (such as the FTS mentionned below?)
Maybe you should take a look at Breaking Changes to Database Engine Features in SQL Server 2008 for if you go with 2005 and try and upgrade later.
Personally at this stage I'd go with 2005 and avoid the features outlines in the article. Your customers/application/developers won't lose out on much (if any) functionality.
Database systems are one of the areas that considering the change is costly. From what I have seen so far, since 2005 works pretty well, large projects are probably still using it (some large projects even still use 2000). However, it doesn't mean 2008 is bad or doesn't worth it. If you are considering a new project, you should probably go with 2008. I don't think there are any big downside to do so.
About TFS, I got to say, team foundation server has one of the worst installation experiences I have ever seen in a Microsoft product. I believe it's an issue with TFS not SQL Server 2008. By the way TFS SP1 is compatible with 2008, but you have to integrate the service pack first.
One downside to 2008: Full-Text search is slower (in some cases, at least). This hit Stack Overflow (the link is to the SO blog). There are good reasons behind the change, but it's worth knowing about before you start.
If you don't need any of the functionality of SQL Server 2008, then I would recommend using SQL Server 2005 SP3. This is a mature, robust and feature-rich database platform. I am currently implementing a strategic database platform for a client right now and have standardised on SQL Server 2005 SP3 64bit clusters. None of my client's applications require any SQL Server 2008 features, and I get the comfort of knowing that SQL Server 2005 has been used in the field for three years now.
Main downside: you will be discovering the new bugs and you will be waiting for the corresponding packs or hotfixes. Please have a look at this page (cumulative update pack 11 for SQL server 2005) or navigate in the Microsoft Knowledge Base, close your eyes and imagine all the pain other users went through when they discovered these buggs ...
EDIT: we do not use SQL 2008. We do not need any of its new functionalities.
This is always a risk in moving to a new version of a program. These are some questions you should be asking yourself:
Have you already completed a lot of manual testing on the old version?
Can you cope with a bug in the new version?
How long has the new version been in use by other people?
Are you at the start or end of a project cycle?
The big risk in not moving to the new version now is that:
You will be forced to move later and that may not be such a good time for you. (But you may be able to skip a release so not having to repeat the pain as many times)
You can’t use what has been added to the new version
In the long term a lot less people will know how to use the old version
It is not good for your staff’s CV to be using too many very old versions of different things – hence it may affect your staff turnover etc.
So you need to plot, “pain” and “benefit” against time and then you will clearly see the right time to move; however we can’t see forward in time, and we can’t move back in time!
Could the SQL Server IDE ever become an application development platform for enterprise applications? In a similar way to the old xBase applications, but, you know, better?
The main reason is that the Management Studio is one of the best “data centric” application I’ve ever used. It has most of the main ingredients for the proposed solutions:
powerful data manipulation language (SQL :o) )
good security
distributed architecture
The main features that it lacks:
a GUI toolkit: something simple and standard, enterprise applications usually don’t require fancy UIs
some form of automation (.Net, COM, I really don’t care as long as it works)
MS Office integration (especially Excel)
So…?
UPDATE:
The question above is a request for feedback on an idea. I'm not planning to use SSMS to build an interactive application in the near future. I would really like to hear what do you think about it and what other suggestions you might have (maybe there is already a product which does exactly that).
A shorter text for the question would be "If SSMS and MS Access could marry, how would their child look like?"
2nd UPDATE:
"Microsoft announces its new product codename 'Frankenstein'. The new product tries to combine the ease of development of database applications from the old Fox Pro and Access times, with the brand new SQL Server 2012 suite. As 'Frankenstein's Product Manager, Jim Bob, stated "[Frankenstein] will enable the developers to shut the f*#k up, and just build that thing already. Not spend their (highly remunerated) time arguing what's the best ORM, or AJAX toolkit, or should they use SOA etc... (btw, since 2009, SOA is dead)"
Well it depends on what way you look at it.
You can extend and build plugins for management studio but you can also use the visual studio shell as the base for new applications (altho I don't think this is what you want?)
However re-reading your question it looks like you actually want to build applications for SQL server. In that case you might want to check out Visual Studio Team Systems Database Edition
There's two risks involved with building applications on top of SQL Server Management Studio.
First, SQL Server Management Studio has been fairly consistent from 2005 to 2008, but that's only three years of release time. SQL Server 2000's tools were dramatically different, and there's no reason to expect SQL Server management tools to always remain the same.
For example, at the Professional Association for SQL Server (PASS) Summit in Seattle in 2008, Microsoft demoed a new management framework for SQL Server. The databases will be packaged and managed in a way quite different from what we're used to in SSMS. Project Kilimanjaro (think of it as SQL 2008 R2) will be the "down payment" on that management, with the rest of the tools coming in later versions. SSMS will look, feel and work differently in order to accomodate this new way of building database-driven applications.
Second, Microsoft's architecture for SSMS is not pluggable, and they haven't encouraged any third party development inside SSMS that I'm aware of. You can build some level of interactivity by using RDLC reports - standalone SQL Server Reporting Services applications that run inside SSMS - but for the most part, you're not encouraged to build atop SSMS because they do want the right to change it when they need to improve it.
I've got good news, though - you mentioned that you'd want some kind of Office tie-in. Keep your eye out for Project Gemini announcements. Donald Farmer did demos of it at PASS, and there's probably some video circulating around. It uses Excel as a front end for BI analytics, and they used million-row-spreadsheets that were storing data back in SQL. There's not much out out yet for the public, but keep your eyes peeled.
To answer the shorter question - Have you seen the various Frankenstein films?
The longer question - why would you want it to, you already have Visual Studio? SSMS is an excellent environment for developing stored procedures, queries, views and the like, lets leave it that way. And anyhow, the only good XBase environment was FoxPro and look where that ended up.