A client wants to host their MS Access 2003 backend database into SQL Server 2008 that resides in a different server. They will be using upsizing wizard to move their databases and tables into SQL server.
A client also has MS Access front end application written in VB. After upsizing their database tables to SQL, they want to use SQL server to read/write data and also use adv. programmability features of SQL Server like stored Procs, functions etc. My team will host their SQL database.
Client will have a growing # of users entering data. So what would be the best option for our team to provide access to our SQL server so that they can use only their databases in our SQL Server?Is there a way to provide them a connection string or something like that so that they could test it in their front end application to see if they could connect to our SQL Server to read/write?Basically I want to know What are the different avenues to connect MS Access 2003 front end application written in VB to connect to SQL Server database hosted in a different server so that a user could read/write to SQL database tables? Any thoughts? Thanks.
Actually, how this setup works is not any different than if your developers were using c++, vb.net, c# or even asp.net. At the end of the day these software development tools such as c++, or FoxPro or MS Access are simply tools that let you write software. The ability of Access to connect to MySql or Oracle or insert your favorite X database brand has existed from day one.
As long as your database supports what is called "open database connectivity" then you are off to the races. And how you setup that database server to allow some software written in say c# or FoxPro or MS Access will not really change much of anything to my knowledge.
So Access is just like any other software tool such as c++ or vb.net – it is a tool that lets you write code and you connect that application and user interface to some database system you choose.
The connection technology that Access uses here is based on industry standards and thus your setup and maintains of the server side will quite much be the same for any other application(s) that you have running on premises that utilize SQL server now.
About the only relevant issue here is that in Access you have a choice of two data object models, ADO and DAO. Right now, since Microsoft is depreciating ADO and they are continuing investment in DAO and also recommending to use open database connectivity. For example, Access 2010 ships with support baked in for SQL Azure (cloud sql), and that support is based on open database connectivity.
So at this point time as it did back in 2003 the recommend data object model in Access is to use DAO.
You can read about the depreciation of ADO support in SQL server here:
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx
While a for good number of general exports and imports and that of linking to SQL server can occur 100% inside of Access, those users will STILL need a set of client tools beyond Access to effectively work with SQL server if over time they going to start using SQL server features. This thus suggests they will need some edition of SSMS (Sql server management studio). The free express version of SSMS should more than suffice in this case.
Related
I understand that this is painfully generic and broad. Nonetheless, all the answers on wikipedia and yahoo (none here that I can find) are pretty useless.
I know T-SQL, C#, etc to some degree. I understand the idea of a database. However, I have NO idea what I created when I made a "server" on my computer through Msft SQL Server. Now I can make databases on that server, and I can connect to them with Visual Studio (sometimes) to use with LINQ or "raw" calls.
Please help me understand (or direct me to an article) of what this myComputerName\SQLEXPRESS (SQL Server xx.x.xxx) thing is. I assume the databases are stored locally...somewhere. SQL Server provides access to the DB files? Why can't they be accessed directly?
Thank you if you even read all this. I really can't narrow the question down.
I guess one specific question is "Can I access the databases without SQL Server running?" Where do I even get the connection string?
You are asking multiple questions, here.
However, I have NO idea what I created when I made a "server" on my
computer through Msft SQL Server. Now I can make databases on that
server, and I can connect to them with Visual Studio (sometimes) to
use with LINQ or "raw" calls.
Please help me understand (or direct me to an article) of what this
myComputerName\SQLEXPRESS (SQL Server xx.x.xxx) thing is.
The layout of a database server is as follows:
Server
Instance a
database aa
database ab
...
Instance b
database ba
database bb
...
...
So, when you install MS SQL Server, you install a MS SQL Server "instance". In this "instance", you can create a number databases. Each database has database files, the exact location of these depends on the settings you chose during installation.
I guess one specific question is "Can I access the databases without
SQL Server running?"
You do not usually open dbf(mdf -ldf) files (the database data files) without MS SQL Server, why would you want to ? You should use the backup/restore features inside MS SQL Server.
Where do I even get the connection string?
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28v=vs.110%29.aspx
The "server" is a process/service running on your computer which can be connected to over the network and provides the API to access your database.
"Why can't they be accessed directly?" Is like asking why do I need Word to view Word files, can't I use Notepad for that. Sure you can, but not really.
Another reason is - imagine multiple processes need to access the database. If each reads and writes to the same files, something WILL break if they don't coordinate. Having a separate server process encapsulates all this.
"Can I access the databases without SQL server running?" I mean yes but actually no.
If you want a database that your program accesses directly (or let's say, your program is also the database server in a sense) - then you can use sqlite, or for simple tasks there are also ODBC drivers for CSV, so you can use CSV files as if they were a database. A dedicated SQL server is always better for bigger more complex tasks and data models though.
After seeing a lot of things in the internet I haven't found any explanation between the two file types: .mdf and .sdf.
.sdf would be a compact version of SQL Server (.mdf) I believe. Still they appear utterly different.
Have followed the two tutorials on msdn, i.e. MVC Movie App and the Musicstore. Both use .sdf.
Partial quote (full): 'First of all it should be "|DataDirectory|ASPNETDBContext.mdf" (notice the extension difference). Your applic...'
Both tutorials have the connection string to .sdf, i.e.:
<add name ="MovieDBContext"
connectionString ="Data Source=|DataDirectory|Movies.sdf"
providerName ="System.Data.SqlServerCe.4.0"
/>
<add name ="MusicStoreEntities"
connectionString ="Data Source=|DataDirectory|MvcMusicStore.sdf"
providerName ="System.Data.SqlServerCe.4.0"
/>
Question:
My question is what to use where and when? More over why to use which where.
SQL Server Compact (sdf files) popular in Windows phone for storing some data (small count of data), also it could be used in web sites, but it has poor performance, even SQLite is better.
SQL Server (mdf files) used in big sites with a lot of data. Its more powerful, but cant be used in phones and must be installed on servers.
Look this: Comparison of SQL Server Compact, SQL Server Express 2012 and LocalDB
SQL Server Compact Edition is indeed quite different from "regular" SQL Server.
SQL Server CE is a stand-alone, one-user database that gets loaded by your application on the machine where your code runs; it has all data in the one single .sdf file and support only a small subset of the "regular" SQL Server (and its features). SQL Server CE is great for simple, stand-alone, one-user apps (like phone apps).
"Real" SQL Server is a server product - you install it on a server, your clients only connect to it (typically, the client machines don't have SQL Server itself installed). It's a full-blown RDBMS with everything - stored proc, triggers etc. and thus best optimized to handle structured, large-scale data - think enterprise applications, such as order handling, invoicing, accounting, large-scale databases for multiple users of any kind.
First, the sql server database file is not a full sql server database, if you're creating it in this fashion it's a sql server express. Sql Server Express databases aren't terribly fantastic to use since most hosts don't run sql server express and publishing them is tricky if you then try to get them running on a sql server database. Better to start with sql server first then express and migrate.
the local db is actually sql server compact edition. http://en.wikipedia.org/wiki/SQL_Server_Compact
For connection strings, go to http://www.connectionstrings.com/sql-server/ There is pretty much every connection string available there. To work with SQL Server Express you will need to have it installed, and to manage it you will need to download the sql server express management tools. Generally, most sql express instances are designed to be used with local accounts but if I remember correctly you can use the management tools to create a sql server login.
I am a programmer and am wanting to undertake a project of converting an Access database to an SQL database.
Is this pretty easy to do? Can I just use a tool to create all the tables with the same names and 'copy' over the data?
I know that Access has built in reporting features. Does SQL have these reporting features? If not, is it easy to create them?
You just need to import your access to sql server database.
Check this tutorial:
Importing Microsoft Access 2007 Database Tables into SQL Server
Regards
MS Access is not a database at all, by default, it uses the Jet or ACE database to store data, but Access will also work perfectly well with data stored in a number of other databases, MS SQL included. There is no need to change from an MS Access front-end when you are moving the tables to a new back-end. SQL Server does not have all the user-interface and reporting tools that MS Access has, it is a database, not "a rapid application database development and reporting tool"
Try this one its free from microsoft.
I am currently developing a very simple database that tracks people and the company certifications they hold. This db will need to store letters of certification as PDF files. I was asked to develop this in MS Access, but I think it would be better to build it in SQLServer and use Windows Forms to build the interface. This app will need to be accessible from a public location like a share drive.
My question is, would it be better to do this in SQLServer like I think, or am I full of it and my boss is right on the money? Or are we both wrong?
A good alternative to Access which I use a lot is SQL Server Compact (SqlCe). This is a completely different product than SQL Server Express/Standard/etc. It is an in-process database like Access, it does not run as a separate process or service.
It is free
Full ACID support
Supports multiple connections
Full transactional support
Referential integrity (including cascading updates and deletes)
Locking
T-SQL syntax and SQL Server data types (same API as SQL Server)
Small footprint (~2 MB)
Easy deployment (supports ClickOnce, MSI, XCopy, etc)
Database is contained in a single file you can move around
Supports ADO.NET, LINQ to SQL, LINQ to Entities.
This is an extremely difficult question, without an understanding of the scale of the application. In my opinion, I wouldn't touch Access with a 33.5 ft pole.
Benefits of Access:
No dedicated machine necessary
No problems with portability
Benefits of SQL Server
Better SQL compliance
Better management control
Are you planning to store PDF files in the DB? If so, why?
I choose SQL Server.
An application built on SQL Server will be more robust and support more users than one built on MS Access.
An application built on MS Access can be easier to debug because there is a lack of a server, lack of significant multi-user support, and the entire database sits in a single file on disk that is easily copied around.
Given that, in almost every case, I choose SQL Server over MS Access.
Argh, do the world a favour & use SQL server. Express editions are free, and plenty powerfull enough for your requirements. You can even continue to do the form/report/UI design in Access if you so desire, it can hook up to SQL Server very easily and transparently.
Pros of SQL over access: concurrency, scalablity, reliabiliy, less future developers trying to hunt you down and kill you.
I would almost never use access for a db if I could avoid it, now that SQL Express exists.
If I were you I'd go with what some of the others said and use SQL Express:
http://www.microsoft.com/express/sql/default.aspx
You get all the benefits of a true SQL environment FOR FREE! You can even use the SQL Management Studio as well as leverage Reporting Services (if you download the advanced pack). Download link below:
http://www.microsoft.com/express/sql/download/
Which edition of SQL Server 2008 Express is right for you?
SQL Server 2008 Express is available in the following 3 editions (each is available from the Install Wizard):
SQL Server 2008 Express with Tools
SQL Server database engine - create, store, update and retrieve your data
SQL Server Management Studio Basic - visual database management tool for creating, editing and managing databases
SQL Server 2008 Express with Advanced Services
SQL Server database engine - create, store, update and retrieve your data
SQL Server Management Studio Basic - visual database management tool for creating, editing and managing databases
Full-text Search - powerful, high-speed engine for searching text-intensive data
Reporting Services - integrated report creation and design environment to create reports
SQL Server 2008 Express (Runtime Only)
SQL Server database engine - create, store, update and retrieve your data
SQL Server 2008 Management Studio Express (SSMSE)
Free, easy-to-use graphical management tool for configuring, managing, and administering SQL Server 2008 Express. It can also manage multiple instances of the SQL Server Database Engine created by any edition of SQL Server 2008 including Workgroup, Web, Standard and Enterprise.
Note: This separate download is designed for customers who have previously installed SQL Server 2008 Express (Runtime Only). If you are looking to download SQL Server Express and SSMSE for the first time, please download the SQL Server 2008 Express with Tools from the Install Wizard.
Access, to me, is really a hobbyist tool or for REALLY basic local projects at this point that just hasn't been phased out yet. I'd definitely look to using SQL Express, plus it makes it that much easier to upgrade if you get beyond the 4 GB database barrier in the future.
Go with what you have the best skills in - Access is great for a variety of projects andit can scale really well if you know what you're doing. Conversely, a bad programmer could do an app in Win Forms and SQL Server and produce a badly performing monster.
I personally would go with SQL Express and a Win Forms or ASP.Net front-end as experience shows that these small projects can easily develop over time in to much bigger applications than was originally planned and a well structured database built on SQL Server can scale up more readily to more users if needed.
Hard to say without understand the environment. It could be that all users have Access, but no desktops have .NET Framework (although this would be hard to believe). Maybe all their applications are on Access and that's all the developers and users there know.
Given all that nonsense tho, You ought to use SQL Server Express 2008 and Visual Studio 2008 Express. Hope I don't get you fired. :)
If the application is, as you said, a very simple database, that's what access is precisely for, creating simple databases. You can write both the database and the application forms within the same environment and users won't need to get anything installed.
Be careful though with concurrent access to your application. If you go for the access solution, multiple users won't be able to use the application at the same time. If you want this to happen, you will need the database and the application being apart. This doesn't mean that the DB needs to be SQL server, you can still use Access as your database if you don't require the power of a more complex engine.
EDIT: Just read on a comment that you are planning to have 10 users and less than 1000 records. FORGET about SQL server, you will be wasting your money. No matter if you decide to go for a simple all-access solution or for a distributed web application or desktop app with remote storage, Access is hundreds of times more powerful that what you need. Even for the "toy-ish" engine that access is, you are not using a 1% of it.
I need to migrate Access databases to SQL Server 2005. Since this needs to be done from within a setup so that a customers' installation is transparently migrated to SQL Server 2005, I wonder if it is possible to automate the SSMA toolkit from Microsoft.
Actually SSMA had command-line interface (special console executable in the SSMA installation folder). It was available at some time but I'm not sure whether it made its way to last release. You should ping SSMA support about what versions had it and what examples of its usages are available. I hope this will help you.
To my own knowledge, such an automation is not available. But it is still possible for you to generate the SQL code that creates the database (the one that will begin with the "CREATE DATABASE" sentence) and launch it through your user interface on your SQL server.
To generate this code, you can
Create the access database with the Access toolkit
Generate the corresponing "CREATE DATABASE" SQL code with (for example) SQL Server Management Studio (right-click on database, choose "script database as CREATE". EMS SQL Studio offers a very nice alternative to SQL Server Management Studio
Save the code for further use
With EMS Studio, You can even decide if this code also updates the data. But I'd prefer to automate data transfer through code: you can for example browse the tables (in the right order, depending on relationships), open recordsets (one local, one SQL), and transfer data by browsing the fields (you do not even need to name them) with code like:
(localRecordset links to local table. can be DAO or ADODB; Adjust code accordingly)
(sqlRecordset links to the SQL server. can be DAO or ADODB; Adjust code accordingly)
localRecordset.moveFirst
Do while not localRecordset.EOF
sqlRecordset.addnew
For each field in localrecordset.fields
sqlRecordset.fields(field.name).value = field.value
Next field
sqlRecordset.update
localRecordset.moveNext
Loop