Ever since I started vb.Net programming, I have been using MS Access as back-end for all my programs.
It is easy to publish application with the MS Access database and run it on another PC without installing the MS Access database.
But now, the project I am working on needs a database with high storage capacity which means MS Access is no longer an option and I have chosen to use SQL Server. Now my question is do I have to install SQL Server on any system that the application will be run on? If so, how will I copy the database that I created on my development machine to other system so that my application will connect to it? Or is there any simpler way of doing this?
SQL Server is a client/server DBMS so you only install the database on the shared server. .NET includes SqlClient, which provides the client components needed for SQL Server applications.
There are a number of options for database deployment. Although you could use restore or attach your development database for the initial database deployment, that won't work well for future upgrades (assuming you want to keep data). Consider using T-SQL scripts and/or SQL Server Data Tools (SSDT). That will allow you to create new databases, such as for development and testing, as well as upgrade existing ones.
Related
I'm currently working on a enterprise that uses TFS 2017, and we pretend to upgrade to Azure DevOps. So far I'm just studying about how to implement this TOOL. I'm new on devops things and I have these following doubts... Why do we need SQL Server to install DevOps Azure? What kind of information are stored in there?
In the server configuration wizard, I have the option to select an existing database to use for the Azure DevOps Server that's being deployed... Can I select the currently database that's used by TFS 2017?
Azure DevOps Server and Team Foundation Server store just about everything in massive SQL Server databases.
The main server configuration is stored in the tfs_configuration database and each project collection is stored in a separate database The default is tfs_defaultcollection.
The collection database holds all version controlled files (TFVC and Git), all work items (Product Backlog, Sprints etc), Test Cases and all test run attachments, your Pipelines, Builds and Releases as well as all of the artifacts produced by these pipelines.
These databases can grow considerably.
Whether you can keep your current database server depends on what version you're currently running. SQL Server 2016 SP1+ happens to be supported by both Azure DevOps Server 2020 as well as Team Foundation Server 2017. You could keep using that for the upgraded installation.
But my recommendation would be to install SQL Server 2019, you'll get all of the performance and security benefits of the new server, support for the latest Windows Server platform, as well as a support window that matches your new Azure DevOps Server installation.
You can find the SQL Server compatibility matrix for TFS/ADS here:
Azure SQL Database and SQL Server
TFS 2017 was one of the last versions to require a database for the Warehouse, which is a form of replicated data. Reports can be written to pull data from the warehouse, without impacting the user experience. The database is somewhat deprecated now, especially for reporting. Microsoft promotes the use of the API to pull data from the live database. TFS does however still need its "live" database to store all of the data presented to users. These will be work items, discussion comments, project templates, user mappings to AD, amongst other things.
You will need to upgrade your 2017 Schema to conform to the new standard as defined by Azure, which will be taken care of as part of the upgrade.
What kind of information are stored in there?
Issues, templates, build results, lots of things.
Can I select the database that's used by TFS 2017?
Yes, that will be upgraded during the installation.
I have been supporting a product written in VB6 with an Access database for a long time. In many of the installations a mapped drive was used to allow multiple workstations to run simultaneously. Since it seems Microsoft has broken that recently, I need to re-write everything with a new set of tools.
I plan to use VB.net and I would like to use a SQL database this time for the stability. The problem is that the market I sell to cannot / will not support installing full blown SQL Server and all the complexities of managing it.
What I am not able to find any current info about is whether or not SQL Server Compact still exists, whether or not it can be added to a NON web based project and if it will be easy to deploy and be easy to manage like an Access database was.
When I try to follow the directions to add SQL Server Compact to my project, it isn't available in the Data Source drop down list (there are "Simple by ErikEJ" versions listed but they don't seem to work) I have seen SQL Server Compact talked about with regards to web projects but I am building a locally installed .exe. I can't find ANY current info about what flavors of SQL are available right now to add to a local program running over a peer to peer network.
SQL Server Compact is no longer supported and developed by Microsoft, I suggest that you use SQL Server Express, it allows remote connections (if configured to allow it) and has modest resource requirements. Supports a database up to 10 GB of size.
As suggested, SQL Server CE can still be used but is no longer supported. For file-based databases, Microsoft currently recommend SQLite.
For a multi-user system, SQL Server Express is probably your best bet. It's still server-based though, so the server needs to be installed somewhere. For local databases, you can install on the same machine as the application and attach a data file on demand. For multiple clients, you'll need the server installed on a machine accessible to all and a permanently-attached database.
I have a desktop application (C# .NET 3.5) that uses a SQL server for it's database. I have had a request from the client, however, to make it possible to export the database as it stands, and be able to use it on a laptop without connectivity. They understand that updates to the parent server will not be reflected in these offline clients.
Is there a way I can just save the DataSet's to a binary form and write them to a disk and send those files to the offline clients.
There is an entire line of tools and technologies covering this case, namely the Synch Framework. See Synchronizing Databases. See Getting Started: Client and Server Synchronization for a starting example involving a SQL Server Compact Edition file on the client (.SDF file) that is synchronized with a SQL Server central database. Note that the client won't install anything else other than you application, the SQL Server CE is just a few in-process DLLs that you distribute with your app, nothing nearly as complex as a SQL Express edition on the client.
The good news is that Synch Framework no only allows the client to get their own on-the-go snapshot of the database, it actually allows for changes applied while disconnected to be merged back into the central site.
You could either use Compact Edition (aka. SDF files), or you can save the datasets as XML using the built-in method.
Can't you just take a SQL Server level backup and have them install e.g. SQL Server Express on their laptops and restore the database there?
That way you wouldn't have to do anything special in your app at all - just change the connection string to point to the local SQL Server Express instance, and off you go! No mucking around with serialized data sets and stuff......
I'm using Visual Studio Team System 2008's Database tools to develop my databases. On my local dev machine, when I want to deploy schema changes to the SQL Server instance on my machine, I just use the Data --> Schema Compare feature of VS2008.
But with live databases I can't do this because I can't connect to the database directly from my machine and the server haven't got VS2008 installed.
So I was thinking about the SQLCMD tool. Isn't that what VS2008 uses "under the hood"?
I want to use as part of an automatic deployment strategy. I want to be able to publish SQL scripts generated by VS2008 to the server and have an application run scripts on the live database to update the schema.
UPDATE
I'm trying to achieve automatic change script generation by taking the deploy script VS2008 Database Edition generates and comparing it against a live database. Only I want to do it through code, no tool or anything. It must be able to run from a Windows Service on the server.
SqlCmd would work. If you also want automatic versioning support you should check out Tarantino.Net, a database management tool that keeps track of which sql-files have already been run.
I have a WPF desktop application that uses a custom database for storage.
I need to prepare a setup project (from Visual studio 2008) (full setup, not ClickOnce).
I can add the to the list of prerequisites to the application and it does install during the setup of the application.
My question is: How can I run a script during the setup to create the database that the application needs? OR how can I restore the database to the client machine during the setup?
Another related question, what would happen if already exists on the client machine? How to detect the instance name and connection data? And then how to be able -if needed- to change the Connection string used by Entity framework to connect to that database?
Thanks,
Ed
SQL Server Express Edition is generally a really poor choice for a local database. It's a server-class engine that likes to use a lot of resources and runs as a service (so it's using up those resources even when your app isn't running). In other words, it belongs on a server.
The only place I've seen SQL Server Express used on a desktop that almost makes sense is as part of the Microsoft Small Business Accounting app, and in this case you generally install that program on a machine who's primary purpose is doing the accounting for your business.
What you should do is use a desktop or in-process class engine like SQL Server Compact Edition, Sqlite, or even Access. This will also greatly simplify your deployment.
If you insist on pushing through with this, know that the installer will create a new instance of sql server on the system. SQL Server will be fine with this. However, you'll need to account for that in the connection string of your app, and that can be a little more complicated. Additionally, to set up the database you have a couple options:
Create it from client code on first start of the app
Create it with a custom installer action (hard to get right because msi permissions)
Distribute an pre-build *.mdf file and attach with custom installer action or on first start of the app.