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
Related
I've been running into an issue recently when I attempt any tutorials that involve using a SQL database, entity framework, dapper, etc.
When it comes time to publish a database, or utilize an ORM, I'm given duplicate options for the same localdb under SQL Servers. Furthermore, then I attempt to publish, the database doesn't show up under the localdb that I've chosen.
I'm wondering how I go about removing the other SQL Servers and just having the one available.
If you look at the image below, the Browse option gives me two of the same LocalDbs. Plus I also get a 3rd one under \ProjectModels. I'm wondering what's causing this and how it can be fixed since no matter which one I choose, the sql database I attempt to publish doesn't show up within any of them.
My advice is not to use this method to publish the database. (right click to delete)
Please refer to this official documentation.
File-based databases like SQLite or SQL Server Express are designed to store their data in easily transferable files that can be served with your application/site.
"Copy to Output Directory" Property of the database file to "Copy if newer". Just point the address to it.
If you are using a server-based database like SQL Server, MySQL, etc., you need to make sure that the target machine/environment has the same database server installed, and you need to write a deployment script to append the pre-populated data files to the server. This might be troublesome for you.
You can also refer to these links. 1,2,3
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 have a questions regarding databases for ASP.Net 4.0 MVC3 (or 4 Beta).
I'm fairly new to the ASP.net MVC environment, and usage of databases in general.
It's stated that the SQL Server Compact is a local database storage. What does this exactly mean? If I were to use this for my web app, would users be able to "access" this database (e.g. register, login), or would I be the only one with access since the file (.sdf) is "local" and is only in my hard disk?
Let's say I'm coding a library management system which would require storage of alot of stuff in the DB. Would it be better to just use the SQL Server Compact that comes with Visual Studio or should I switch to MySQL or some other databases?
I'm asking because I wanna clear everything up before I step into the world of ASP.Net (and since I'll be dealing with DBs alot in future).
The "local" is relative to where the application code runs, not where the user is. If you're using ASP.NET MVC, the application code runs on the server, to the database has to be on the same server. All users using the web application can use it though since the access is done by the application.
I'd use SQL Server Express for that, version 2008 R2 does have a limit of 10GB per database (not including FILESTREAM data AFAIR) but that is already a lot of data. It's free but uses the same engine as the full SQL Server products, but it has some limitations on database size (as mentioned) and resource usage (parallel processing and memory), for many application it is still a perfect solution though.
No, in this case "local" means that it's contained within the package of the web site itself. You'll want to deploy the database file along with the website (but take care not to overwrite it in future subsequent deployments), of course. But the idea is that the database is a file that you put on the server, not a service installed on the server.
Define "a lot of stuff." I doubt you're going to exceed the capacity of SQL Server Compact, or absolutely require features it doesn't provide. You'll want to compare all of the features available in the various databases. (Size limits, native data types, ease of integration, ease of management and deployment, stored procedures, etc.) Chances are any database will work for you, but you'll have to define your needs in more terms than just "a lot of stuff."
1)
SQL SErver Compact edition is a light weight free, embedded, database engine that enables easy database storage. That means you dont need to install any software in a computer for this database to work. you can simply copy the dll of SQL Server compact edition and put in your bin directory and start using it. No additional setup or security permissions are required for it to run.SQL Server CE Stores database as a files on disk. The file extension will be .sdf You can store SQL CE database files within the \App_Data folder of your ASP.NET Web application
Here is how it looks like in a project.
You can do the same things you did with a standard sql server express instance with SQL CE too. So your users would be able to access the data ( thru your application).
2) SQL Server CE would handle this up to an extend. If you have so much data coming in, you probably want to try something bigger like SQL Server express edition etc.. But the migration is easily doable because it is a miniature version of the real SQL Server Database.
If you are in a shread hosting environment and dont have the ability to install / get access to SQL Server instance, you can go with SQL Server CE as it is file based.
This is a good reading to start with : http://weblogs.asp.net/scottgu/archive/2010/06/30/new-embedded-database-support-with-asp-net.aspx
We're developing an aspx project with Visual Studio 2010 Professional, SQL Server 2008 R2 and Team Foundation Server 2010. Since the development is being carried out in multiple offices, each developer has their own local instances of the databases.
I want to bring these multiple databases under source control (or at least the schemas of the DB, structure and stored procedures - data doesn't matter to me). My preferred approach is to add database projects to the VS solution, which is already source controlled in TFS. Any changes will be distributed by TFS, and can be deployed locally.
The problem I'm having is that the database projects contain a reference to a local database instance (server & name). When someone gets the latest version of my changes, they will have a reference to my local DB instance (which is different to their local DB instance). They would need to change the DB details (thus checking the dbproj out) in order to get my updates.
So, is there any way that the database server & name can be left out of source control while the schemas remain under source control? Any help would be much appreciated!
I'm not sure if you can. However, you could use an alias, so all of the developers use a database on their local machine, but referenced by the same alias.
Take a look at: http://www.mssqltips.com/sqlservertip/1620/how-to-setup-and-use-a-sql-server-alias/ for how to set an alias up.
That way you can separate the database from the connection details.
I'm involved in developing a unique enforced database source control solution called DBmaestro TeamWork.
It has a plugin to SSMS which allows the developer to work directly on the database objects (change their working environment), run their tests and then perform Check-In which reads the metadata (tables' structure, procedures, functions, views etc.) to the version control repository.
With the Impact Analysis it is easy to merge changes from different databases to a single database.
The impact analysis algorithm perform 3-way analysis (not just a simple compare & sync) to identify changes origin from developerA which should not be reverted when developer merge his changes and it ignores the database name when running the impact analysis or generating the delta script.
I have a DB on oracle on Windows Server 2003. How do I export it with all the data and put it into other Windows server?
Use RMAN to take a full backup. Then restore it on the new server.
See Clone using RMAN Article
You can use Oracle Data Pump to export and import database. Quote from documentation:
Oracle Data Pump is a feature of Oracle Database 11g Release 2 that enables very fast bulk data and metadata movement between Oracle databases.
Procedure is like this:
Export existing database using expdp utility
Install Oracle database server on new Windows server
Import database on new server using impdp utility
Check this link: Oracle Data Pump. There you will find complete documentation and examples how to use this utility.
If you are wanting to create an exact copy of an existing database on a new sever of the same operating system (though not necessarily the same O/S version) and the same Oracle version, the quickest and least problematic method is to just copy the database files. This is often referred to as database cloning, and it is a common method DBAs use to setup development and test databases that are intended to be exact duplicates of production databases.
Stop all instances of the database on the existing system. You could login to each instance "as sysdba" using SQLPlus and run the "shutdown immediate" command. You could also stop the Windows Services for the instances. They are named OracleServicesid where "sid" is the instance name. Usually, there is just one instance, but there could be multiple instances to a single database. All instances must be stopped for this procedure.
Locate the database files. Look for an "oradata" folder somewhere below the Oracle root folder and then find the folder for the database sid in there. (There could be multiple oradata folders. You need to find the one that has the folder named for the SID of your database.) There are also the files in the Admin folder for the sid as well as the %ORACLE_HOME%/database folder. If DBCA had been used to create the database, then the location of all of these files varies by the Oracle version.
Once you have identified all of the files for the database, you can use any method at your disposal to copy these files to the same locations on the new server. (Note: The database files, control files, and redo logs must be placed in the same locations (i.e., file system paths) where they exist on the old server. Otherwise, configuration files must be changed and commands must be run to alter the database's internal file paths.) The parameter file (initSID.ora) and server parameter file (spfileSID.ora) must be placed in the %ORACLE_HOME%/database folder.
On the new sever, you must run the oradim utility. (Note: oradim is an Oracle utility that is specific to Windows and is used to create, maintain, and delete instance services.) Here is a sample command:
oradim -new -sid yourdbsid -startmode automatic
Startup the database with SQLPlus, and you should be in business.
This is a general overview of the process, but it should help you get the job done quickly and easily. The problem with other tools is the need to create an empty database on the target server before loading the data by whatever means. If the target server has a different version of Oracle, it will be necessary to run data dictionary scripts to upgrade or downgrade the database. (Note: A downgrade may not always be possible.) If the new server has a different O/S, then the above procedure would require additional steps that would significantly increase its complexity.
It also possible to duplicate a database using RMAN. Google the words "clone oracle database using rman" to get some good sites on how this is done using that tool. If you are not already using RMAN, the procedure I have described above would probably be the way to go.