Does MS SQL Server Express save one database per file (like SQLite, which I cannot use)?
I am asking because I want the users of my app to be able to easily exchange databases.
So, several files would make the whole procedure too hard, which is why I would use another DB then.
SQL Express uses 2 files per database one with the extension MDF and another with the extension LDF. You'll need both for your database to work. I have never tried to copy the files from one machine to another. I normally backup the files from one machine and restore to another machine and overwrite a db that already exists.
That said it looks like you might be able to copy the files from machine A to machine B and then on machine B, with SQL manager
Connect to the SQL Server (localhost or whatever)
Right click Databases folder
Left click Attach, Add
Point to the MDF you want to start using
and you should be good to go.
SQL Server Express software is not in 1 file. However you could have the database data in a file. You may want to consider SQL Server CE. SQL CE databases reside in a single .sdf file which can be up to 4 GB in size. See more here: WIKI-Expres-CE.
Related
We are maintaining Microsoft Access 2016 database for Locker Management Inventory. The database contains complex queries (Computed Columns) , Reports and Database backend file is also on the same computer.
We are required to use SQL Server Management Studio 2012 as our Back-end for Microsoft Access Forms and this form is required to be accessed by 10 Users on LAN. Please guide Step by Step Procedure for this task.
Thanks in Anticipation.
Access is inherently multi user and has no problem linking to tables on a SQL Server that is on the same LAN.
The design steps are typically to design the application in Access, unsplit, in a single file. Then when the app is ready - one splits the file into a back end and front end that are linked. One can copy the front end multiple times for multiple users.
These steps above are all Access and you'll find good documentation online and in any textbook for the Access database.
The final step, if one must use SQL Server as the back end, is to then import those tables from the Access back end file into the SQL Server. This is not uncommon but the instructions for this would be in SQL Server area.
Hope this helps.
One must understand the fundamental architecture: a multi user Access application is 2 files: front and back (this is actually what they are called). There is only 1 back file - it is where the tables are held. The front file can be copied repeatedly, 1 per user, and all fronts link to the single back end file.
SQL Server is the back end and Access is the front end - in your case.
One only really needs the SQL Server product as the back end file if the payload is particularly high. Pay load is combination of the quantity of records and simultaneous users.
The basic approach is to split your database into two parts. A built in database splitter is built into Access. Once done, you could in theory just place the back end accDB access file on some server folder that is shared to everyone. You then use the linked table manager in Access to link to the back end file.
Since you been “mandated” to use SQL server, then you would migrate the back end accDB file tables to sql server, and then re-link (again use the built in table manager) to link the tables to SQL server. So the process for linking to an access file, or linking to sql server is near identical. The end result is your access application will now be using tables that reside on SQL server. From a developer and even user point of view your forms, code, reports etc. will continue to run as before.
And as a general rule it only makes sense to run SQL server on your machine for development use. You would have to copy/transfer the sql database to that “mandated” instance of SQL server they are telling you to use that presumably is running on some server. It would not make sense to mandate use of SQL server without you being provided with some server running SQL server.
It certainly is possible to allow users to connect to YOUR computer running SQL server, but that seems less than ideal since if you re-boot, shut down or your computer freezes, then all other users would suffer a connection break and much inconvenience.
I mean, right now if you have a shared folder for all users, such folders are typically NOT placed on one users computer, but some dedicated machine that acts as some kind of server for everyone.
So if they are telling you to use SQL server, then it quite much assumed they are providing a dedicated machine that is running SQL server. So certainly for development you can (and even should) run SQL server on your machine. However you would then have to transfer that database to the computer/server they are telling you to use with SQL server. And then you would re-link your Access application tables to now point to that production server. The last step would be to then distribute this correctly linked application to each user. So just like all software you purchase such as word, or Excel, you STILL install that software on each computer. Now that you are building software, then you as a developer will adopt the same concept – that is to distribute and install your software on each workstation. So while you might use word or Excel (or Access) from the local computer, you also may well often “share” some data files (but NOT the application) on the server.
As long as the application you distribute to each workstation is correctly linked and points to the server based edition of SQL server, then you all be sharing the same database. You will NOT in practice have multiple users working on and using the application you created, but distribute that Access application to each workstation. How you “get” that application to each workstation is not really any different then how you would supply a word document or Excel sheet – the only requirement here being that each workstation gets their own copy. Since each users copy of this application has linked tables that point to SQL server, then you all working on and sharing a common database.
So the first concept to grasp is that of spitting a database. I explain this concept here:
http://www.kallal.ca/Articles/split/index.htm
As for some steps and migrating to sql server, here is a great starting point:
https://www.fmsinc.com/MicrosoftAccess/SQLServerUpsizing/index.html
I am trying to use Copy Database Wizard to copy from my live server (shared hosting) to my local machine. Both the live and local servers are SQL 2008 R2.
I have used CDW for several years with perfect success when copying from a live SQL 2000 server to my local 2008 R2. But now that I have migrated my live database to SQL 2008 R2 the CDW is giving me this error:
Could not read metadata, possibly due to insufficient access rights.
I've learned that this error can be predicted before you even complete the CDW setup: On the page where the CDW asks you for your desired destination database name, it is SUPPOSED to populate the .mdf and .ldf files with their name-to-be and size (e.g. MB, GB).
But in my case these file names and sizes are not being shown (area is simply blank in the wizard) and then of course when I attempt to execute the package it gives me the error.
After much research I believe that reason for this error is due to the CDW requirement of "You must be a member of the sysadmin fixed server role on both the source and destination servers."
On my local server, my Windows Authentication login is listed as a Role Member for the sysadmin Server Role. However on my live server (keep in mind it is a shared SQL server with 250+ databases) the only Role Member listed is [sa].
Am I right in thinking that the only way to satisfy this requirement would be to add my specific SQL user to the live/source Server > Security > Server Roles > sysadmin role? I'm guessing that would never be done on a shared server right? Or is there some other way to make it work by messing with the specific database properties/users/roles?
I can't explain why CDW is working from the live SQL 2000 server and not the 2008 R2. I HOPE it is simply that something isn't set up right on the live database, but maybe it is due to changes that were made to SQL security over the years.
In case it matters, I must use the SMO method instead of detach/attach because it is a live database that I don't want to take down. Historically the CDW from SQL 2000 only takes 3 minutes with SMO method so speed isn't an issue anyway.
Here's my preference for a solution:
Find a way to get CDW to work, most likely by changing something on the live server. Is this possible? What would it be?
If that fails, then...
What about an idea of using CDW to create the package, but then going into to BIDS and manipulating something in the package to circumvent the sysadmin role requirement. (Does it really need the metadata? I don't need anything beside the actual data tables.) Is this possible?
UPDATE 6/14/2016: Editing a CDW package in BIDS won't work as it appears to simply use the .mdf and .ldf files, which of course I don't have access to on the shared server. I think an alternative is to use Import/Export Wizard to create a package, then edit in BIDS. The annoying part is that without access to metadata the Import/Export Wizard doesn't seem to be aware of Foreign Keys, and thus doesn't know what order to process the tables in.
If that fails, then...
Is there any other way to easily automate a daily copy from my live server to local machine? The reason I like CDW is because it is super simple to use (when it works), it can be scheduled to run daily as a SQL agent job, and requires no manual work on my part. Is there a "next best thing" if CDW can't be made to work?
You'd think that a very common scenario for all websites out there would be "how do I get a copy of my live database onto my local SQL server, daily, automatically"? But maybe I'm the weird one!
Another simple solution would be the Import/Export Wizard.
In SSMS right-click the database you want transferred and select 'Tasks' and then 'Export Data...'. It will open a wizard that is very similar to that of CDW. The difference here is that I could not find a sysadmin requirement to use it.
At the end it will give the option to run immediately and/or save the SSIS package. If you save the SSIS package (I prefer to save it to disk) you can then create a schedule via a SQL Agent job.
Have some application which uses SQL Server database on client server. Some time ago client requested to install application on external disk to be given someone else. My problem is somehow i have to attach database on external disk. Is it possible somehow to install sql server database on pendrive along with application? I heard something about sql compact. Can you update me on that topic?
I have not used SQL Compact but SQL Compact is suitable for in-proc, small, light-weight databases but has certain limitations as compared to SQL Express, no support for views, stored procedures, remote data access etc. You can find more at sql-express-v-localdb-v-sql-compact-edition
In a recent project, one of my clients had similar requirements and this is how achieved it with SQL Server Express.
As per my configuration I placed both the application and the database on the external disk. The database was placed in a subfolder named Database in the Bin folder. I declared my connection string as
Data Source=SERVER_NAME\SQLEXPRESS_INSTANCE;AttachDbFilename=DATABASE_FILE_NAME_WITH_FULL_PATH;Integrated Security=True;Connect Timeout=30;User Instance=True
As a quick solution SERVER_NAME\SQLEXPRESS_INSTANCE was configured and taken from App.Config but DATABASE_FILE_NAME_WITH_FULL_PATH was generated dynamically (external drive letters may change) using path constructs such as Path.Combine(Path.GetDirectoryName(Application.ExecutablePath), "Database\ABC.MDF") etc. and inserted into the DataConnection string. So, whenever the application runs it searches for the ABC.MDF in Database subfolder of application executable path. You may need to tweak this approach as per your requirements such as Application.StartupPath / Application.ExecutablePath etc.
For more information and another example on AttachDbFilename check MSDN system.data.sqlclient.sqlconnectionstringbuilder.attachdbfilename
I want to migrate a database completely or partially. Right now, I will do a complete database. Partial will be posted as a separate question.
Strategies I am considering:
copy database wizard
convert 2005 database to script. Run script on 2008
simple SQL query
My question - I want to use method 2. Is it even possible to do this? If yes, how to do it? Any limitations/risks ?
NOTE - The source server is a SQL Server 2005 database with one IP. Destination is a SQL Server 2008 instance with another IP.
I don't know if you need to be sysadmin to do this. I am not even sure if I am sysadmin. If yes, then how to check if I am a sysadmin ?
Just RESTORE it on the SQL2008 server and it will be automatically upgraded. And you can check if you're a sysadmin using IS_SRVROLEMEMBER.
My question - I want to use method (2). Is it even possible to do this ? (...) any limitations/risks ?
Option 2 could be a problem if database is too large. Worked for me with up to 2 GB databases.
any limitations/risks ?
You may need to increase SQL's buffer and/or run the script through command line, since a large script in SQL Manager eats up plenty of memory.
If yes, how to do it ?
To generate the script, simply right click and choose generate script. Select both data and model for whole database, and choose appropriate options for others.
As Pondlife said, Just backup the database at SQL 2005, restore as a new database at SQL 2008. You change the compatible mode to SQL 2005 which is version 9, or you can leave it to 2008 which is version 10 or 10.5. I think you want to keep the database as is, so you could set the compatible more to 9.0.xxxx and you all be done.
As usual grant access to users, create them as new if you have to, or migrate them from SQL 2005.
Generating script from 2005 and running on 2008 is a long route. There may be some possibilities for errors and TSQL compatibility.
Hope it helps !!
Most simple way to do this is to restore backup or copy MDF and LDF files to new server. If your servers are in the same network you can do this by creating shared folders on the second server and copying files there.
If that is not an option for any reason then you can zip the backup (make sure to add strong password) upload it to some online storage and then download it from second server.
Final option is to use third party comparison and synchronization tools from RedGage or ApexSQL (there are a lot of these on the market and they all have fully functional trials)
One of the tasks in a project that I'm working on is to migrate an existing database on SQL Server 2000, to a new server which runs SQL Server 2008. This database is extremely huge, with 23 million rows and a 78GB mdf file.
What is the best way to migrate a database of this size?
My current approach would be to:
allow for application downtime so that the application doesn't write records to the database
perform a full backup on SQL Server 2000.
move backup file over to new server across the network.
restore full backup on SQL Server 2008.
configure the application to refer to the database on the new server
restart application.
decommission the database on SQL Server 2000.
However, I'm not sure how much application downtime that would involve.
Are there any easier approaches, or an approach that involves very little downtime? Can a backup be taken while the application is running? Obviously I would need to stop the application when the backup file is transferred and the restore is completed. Interested to hear your approaches to a task like this.
If you're open to downtime:
Detach the database
Copy data file(s) and log file(s) to the new server
Attach the database on the new server instance
Detaching closes the database and finalizes the files so they safely can be moved (or backed up via filesystem backup). It will no longer be accessible on the server instance until you reattach it.
Don't cut and paste / move the data and log files, just in case something bombs during the copy.
There are several other things to keep in mind when migrating to a new server instance, like making sure logins exist on the new instance, features in use that might be deprecated, etc.
Here's the reference for detach/attach.