I've happily created an MSSQL database which, from my point of view, works well and gives me what I want. If the boss wants info from it, he could ask me. It would be better if it had a front end.
I've looked around and seen recommendations for Visual Studio/Lightswitch and ironically am a little in the dark....
1) Presumably VS 2013 and Lightswitch aren't the same thing, or is the latter part of the former?
2) I've easily connected my SQL to a trial version of VS 2013, but cannot make what I would call 'forms' in any other app (such as Access) which can call and update data.
3) Before I venture on and spend further time in this avenue, does anybody know if VS2013 would be able to build the app I need on a desktop to access SQL?
Thanks in advance
Related
Our team has been using Microsoft Access 2010 as a frontend for an SQL Server 2014, and are dependent on the Upsizing Wizard in Access to migrate tables from Access to SQL.
For example, if there is an SQL database named papers, our team has an Access file named papers_temp.accdb. When we want to make changes to a given table (or create a new table) in the papers database, we do this locally in papers_temp.accdb before using the upsizing wizard to migrate the given table from Access to the SQL database, overwriting the table in SQL if it already exists.
From Office 2013 and Access 2013, the Upsizing Wizard is gone, and we are in need of an alternative. Is there a similar tool available for Access 2016, or do we have to adapt to something else entirely? So far open to suggestions.
SQL Server Migration Assistant for Access
I've been exploring this program for the last couple of days, after finding many recommendations for it on the web. It appears to be able to do the upsizing and migration that we need.
However, more often that not, when attempting to select (and load) a table, the program is stuck in a loading process that never seems to end (tried waiting for one hour), meaning I'm forced to close SSMA without saving my project. In general, the program does not seem very stable, and we'd prefer to find a solution that was more familiar to work with.
Perhaps I'm missing something?
Correct, the upsizing wizard has been deprecated and the replacement is (SSMA).
The latest version as of today is:
Microsoft SQL Server Migration Assistant 8.5 for Access
https://aka.ms/ssmaforaccess
In my testing I have learned that it is not compatible with the 2019 O365 version of DAO and you cannot install the correct version of DAO along side O365. This means that this solution is dead in the water. Microsoft has updated us in to a corner where we can't use any of their previous solutions on the latest version of Access. At this point I think we are waiting for MS to update the tools to support the latest version of O365 Access.
If you are stuck in this boat with us the only other option is 3rd party software.
We are planning to put out SQL Objects (Tables, StoredProcedures, UDF's and Views) under our existing TFS 2010 versio control.
Is is possible that any check-in's made to the objects under TFS version control gets automatically sync'd to our Development server. The technical team here are not so interested in having to make changes at 2 different places (Development Server + Check-in at TFS server). Its an overhead process change for them.
Late answer, but I hope it can be useful:
Recently, I've tried to find the solution for a similar problem, and I've bumped into a sql source control add-in for SSMS that works with the TFS, and I found some answers by reading this article:
SQL source control reduce database development time
I think it can be useful for you too (in case you couldn't solve your problem)
Hope I helped.
The best solution by far to do this is to use Red-Gate Source-Control. You will not find a better and easier product to do this, and all the other benefits you get from using it is huge. For example, it integrates 100% into SQL Management Studio.
You should use Visual Studio Database Projects. You'll get the best of both worlds! Source control and automated builds and deployment.
I found the solution to my unique scenario. I used the Sql server management studio project by using the TFS plugin for SSMS. Team can now easily make changes in the Development environment using SSMS and make check-ins at the same place. Nice and easy way to do things without additional overheads. However, this only solves the purpose of version control. I am still researching on how can we do schema compare and automated deployments using SSMS projects.
I need to know wether or not to buy the VS 2010 premium or not. I have the Visual StudioTeam System 2008 Database Edition working on my own version of vs 2008 team suite. My coworkers only have VS2008 professional. We are moving to VS2010 now. We do not have MSDN licenses for our company right now. We are looking to buy just the VS2010 no MSDN. It is very pricey to get 6 licences of VS2010 premium. We need to get our database into source control. We are currently email scripts around, and it very difficult to keep track off. Are there any non-microsoft solutions that would be the same features and be free?
Does the entire team need the Premium functionality? Contrary to the title of your question, VS2010 Professional does include the Database Project. What you don't get is schema compare, data compare, data generator, unit testing, refactoring, and static code analysis. So one compromise option would be to get one Premium for the person who needs the above tools, and leave everyone else with Professional?
How much time do you lose on your projects emailing data model changes around? How much extra time does the team spend debugging because of using that process? If you add up all that time, look at what could have been built instead and general developer happiness; maybe the price for VS Premium isn't so bad.
I'm just saying its easy to be blown away by sticker shock on tools until you add up all the lost time that could have been going to money making product development.
For database projects you definitely need what they call a "data dude" (Database Edition) or Team System (for 2008).
For 2010 it's either Premium or Ultimate.
Another option would be to move database development into the main (non-database project) by using some ORM tool. Either Linq2Sql, Entity Framework or a third party solution like nHibernate.
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.