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.
Related
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.
I got a .db database file which one of my friend created through PowerBuilder 6 in Win98. Later I wanted to test that database file, but was not able to view or open it in any of common db viewer and not able to get any data out of it.
please help..
I am using Win7 and do have xp(virtual).
The problem with your description is that PowerBuilder is database-agnostic, so it could be any type of database if it was being used with a PowerBuilder application. However, if you want to go with probabilities (and I'm not sure this is how PB is used most; at one point the most popular database used by PowerBuilder was Oracle), PowerBuilder shipped with a run time license for SQL Anywhere, a database that was originally Watcom, acquired by Powersoft, which was acquired by Sybase, which was acquired by SAP.
Supposing the database you have in hand is SQL Anywhere, you need to get a SQL Anywhere engine. Probably the first thing I'd try is downloading the Developer version of SQL Anywhere and just try to open up a copy with that, see if the software will migrate it to the current version. (My bet is that it will, or will at least provide you with a means.) Another way to get a current version of SQL Anywhere (I think; I haven't tried this in ages) is to download a trial version of PowerBuilder 12.5, which I think comes with SQL Anywhere (the paid version does). If you get that up and running, then you can use a pipeline object in PowerBuilder to pretty easily move data from one database to another. And, for kicks, you can migrate up your PB6 app to see if it still runs. (My bet is that it will take a few tweaks, but fewer than you're probably imagining.)
Good luck,
Terry.
Your .db file is probably a Sybase SQL-Anywhere database. You need to know which version of the engine was used to create the database and then you need the ODBC driver to access that database.
I have, admittedly, done very little searching on my own, so feel free to insult and/or harass me.
I have two databases that I use, one for development and one for production. In Visual Studio 2010, I have simple overrides that change the connection string based on whether I'm building for Debug or for Release.
Right now, I manually change the database schemas when needed. I've thought about creating scripts, but I'm wondering if there is a better way? Can I create a DB in Visual Studio on my local computer, migrate those changes to the development SQL and then, finally, migrate up to Production so that the schema version matches the release?
Thanks in advance!
.NET 4 | Visual Studio 2010 | MS SQL Server 2008
Are you familiar with Visual Studio Database Edition? It's reason for being is to help you with what you just described. Not only does it allow you to version control your database schema, it allows you to build deployment T-SQL scripts to update a database from one version to another. It has built in schema compare and data compare. I highly recommend it. We use it to version control our database schema and to do deployments. I would never attempt to update database schemas by creating manual scripts anymore.
This used to be a pain in the ass for me. Then I bought this: http://www.red-gate.com/products/sql-development/sql-source-control/
Which, providing your're using a compatible Source-Control solution (such as SVN), you can make changes in one database, commit them, and then update other databases with the same structure.
As Randy mentions, the Database Edition of VS.NET will do this.
I use SQL Delta. It's a third party tool and very well priced for what it does. I've used it for a number of years on extremely large projects (that is the database has hundreds of tables and thousands of stored procedures) and it has never failed us in what it does.
The way I used it is this.
I get it ot produce a blank database
schema as per the development
database.
Move this database over to
the production server
Sync the production database with this database
You can also produce scripts and run the scripts and all of this can be automated.
I have an old Access application that has a lot of code in forms and reports. The database is getting too large and I am thinking of moving the back end to SQL Server.
My requirements are as follows:
The DB needs to be multiuser and the users (3-5) will need to log in over the web
I would prefer not to re-write the forms and reports in ASP or some other web front end.
When I think about my choices, I see them as:
Have an Access ADP front end and allows remote log-in to the server where it is stored. Not sure if it is possible for 2 users to simultaneously log in
Distribute an ADP front end to the users, but I am not sure if it is possible to connect to a SQL Server back end over the internet, and the network traffic may be an issue.
Any other solution?
I appreciate all help.
u
I would recommend against rewriting as ADP (you do realize, I hope, that you can't convert an MDB to ADP?). ADP has been deprecated by MS for about the last 5 years, and has received no development attention in the last two versions of Access (A2007 and A2010). It may get some attention in the next version of Access, or it may be dropped (as was the case with DAPs after two versions of no changes).
The easiest way to roll out multi-site access to an Access application is with Windows Terminal Server. This is extremely easy to implement and not all that expensive and requires no alterations to your Access application (I assume you'd upsize the back end regardless, of course).
You also might want to familiarize yourself with the fabulous new features of Access 2010 that integrate with Sharepoint Server 2010 and its new Access Services to allow the development of an Access app that runs almost identically in the Access client and in a web browser (via Sharepoint). This would require a major rewrite, of course, but it's also quite scalable.
It's also the future of Access, so far as I can see, and will be getting lots of attention from Microsoft over the next few years.
I work on a clients MDB FE on a VPN/ADSL connection to their server. It's slightly more sluggish in some areas than working in their office. But it does work well. So I see no need to convert the app to ADP format.
Note that they've done a lot of work creating views and stored procedures to greatly improve performance.
There is a tool from the SQL Server group which is better than the built in Upsizing Wizard. SQL Server Migration Assistant for Access (SSMA Access)
Also see my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page.
The only secure way to expose a sql server back end to and access front end over the internet is over a vpn. Unless you rewrite queries and other sql in the access code to execute queries on the sql server, sql server is probably going to transfer entire tables to the acccess front end forprocessing and filtering which will be slow over a vpn. If you really don't want to have to recode i think rdp acess is going to work best.
ADP is definitely faster over a WAN than linked tables. Linked tables are the least efficient thing in the world. Jet didn't get any new features for 10 years.. Access Data Projects get new features through every release including Access 2000, 2002, 2003, 2007 and 2010. ADP has also gotten new features in 2005 and 2008 with the release of SQL Server. ADP has gotten new features with every release, it is NOT depecrated, it is fully supported. There are specific hotfixes released for ADP just like there are for Jet.
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.