We have a .NET 3.5 SP1 application written in C# that stores data in an SQL CE 3.5 Database. We also need to access (read only) this very data from a legacy VB6 application.
I don't know if this is at all possible. There are several approaches to this problem that I can think of.
1) I have read about ADOCE Connections, but this seems to be an option for embedded Visual Basic only
2) I can't seem to get a connection working using ADODB.Connection Objects like so
Dim MyConnObj As New ADODB.Connection
' Microsoft.SQLSERVER.CE.OLEDB.3.5
' Microsoft.SQLSERVER.MOBILE.OLEDB.3.0
MyConnObj.ConnectionString = "Provider=SQLOLEDB;Data Source=c:\test.sdf"
MyConnObj.Open
Maybe this is just a bad choice of providers? I also tried the providers that appear as comments above and different connection strings, but to no avail. Both providers are not installed on my dev machine and won't be installed on my customer's machine.
3) Maybe there is a way to use a more generic approach like ODBC? But I believe this would result in setup / deployment work, right?
Does anyone have any experience with this scenario? As you can see, I am really looking for some good starting points. I also accept answers like "This is drop dead simple and so are you" as long as they come with some guiding directions ;-)
Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=c:\test.sdf;
Verify that you have the provider available. Start Regedit.exe, open the HKEY_CLASSES_ROOT node, scroll down and verify that you see the Microsoft.SQLSERVER.CE.OLEDB.3.5 key. If it is not there, you have to install it. Download link.
According to connectionstrings.com, you should be able to use
Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=myPath\myData.sdf;
However, the OLEDB provider for SQL Server CE does not provide all functionality.
You could create a COM-visible C# component to extract the data for the VB6. That avoids using the potentially cranky OLEDB provider for SQL Server CE.
It has another benefit in that it adds a layer of insulation between the VB6 and the database structure.
Related
I am developing a Microsoft Kinect game (for Windows) using C# and I need a local database to store information about players and their progress as well as more detailed information on their points and accuracy. I have never used a database within a Windows application and I was looking for some advice on how to do so. I have been trying to use SQL Server because it lets me create a database within Visual Studio. I have been unable to find many resources on how to interact with the database from within the C# application.
I really know very little about SQL Server so I do not know if it is the right choice for what I need. Does anyone have a suggestion for what sort of database system to use? Can you point me in the direction of some good resources/examples on how to do what I need to do?
Thanks so much!
Edit: I should also mention that I do have experience working with SQL.
There are other, more portable, solutions such as SQLite and SQL Server Compact Edition which do not require a separate server installation and are more easily accessed and distributed from within a standalone desktop application.
The usage can be largely compared to an external SQL server and/or Linq to SQL so the actual implementation should not be that hard.
Some interesting links:
How to: Deploy a SQL Server Compact 4.0 Database with an Application
An Introduction to SQL Server Compact Edition
As mentioned in another comment, a simple serialized XML file might also be enough for your use. It's fast, easy and if you don't need to perform any actual database operations but simply save and load everything then it might be more efficient.
Look into using a SQLDatasource and relevant tutorials. This will give you an easy way to get up and running without an intimate knowledge of SQL. Once you have the datasource setup and 'bound' to your database, you can use this to connect your controls (grids,labels,textboxes ect.) to it.
Check this out:
http://www.youtube.com/watch?v=w34BDhDPEEQ
You don't want the fully fledged SQL Server. SQL Server Compact Edition is more appropriate, or there's also SQLite for a non-Microsoft option.
The easiest way to interact with a database from C# is Entity Framework, which ships with .NET 4.5 or is downloadable as a nuget package for .NET 3.5 and .NET 4.
A different, non-relational-database option would be DB4O.
You could use Entity Framework
var player = db.Players.Where(x => x.playerId = id);
var points = player.points;
points =+ 100;
db.SaveChanges();
You could also write CRUD operations against the tables if you don't want to use an ORM
Basicly you will have to make a database with a table, using the GUI of Visual Studio.
Then where necessary in the code, you will have to create a connection with the database using a connectionstring. Then you will have to insert an SQL command using the SQLCommand class and execute it. This requires some knowledge about the SQL syntax, but just search what kind of command you want specifically now and in time you will get the hang of it. Don't forget to close the connection to the database when you are ready with writing or reading data.
I hope this gives the main idea.
Edit: Oh and for this kind of database SQL Server Compact will be enough.
I have worked with Microsoft Access as the back-end of my applications in the past and Visual Studio offers me the choice of copying the database to the installation of the executable that I have created. However, I now want to move onto more complex databases and I figured MySQL was a good start because it's free and popular. I know there may be better options and right now I'm currently only in learning stages so I strictly want to stick with MySQL.
My problem is that I have my MySQL running on my localhost. I have connected to it, ran queries, etc. Now if I wanted to deploy this application to other computers while keeping the database (not web-based) how would I go about doing that? The reason I don't want to go web yet is because I just want to get an understanding without dealing with networking yet. I figured this would be the way to go.
Thank you.
MySQL is not primarily anything. It's a full database as is Oracle, SQLServer, Postgre, etc. that can be used for any application that you feel it applies to.
In your case what you really want is SQLite for "embedded" database needs. The database is represented by a single file that can be opened and queried very similarly to MySQL.
http://www.sqlite.org/
To access the database from your C# code there are many libraries available to you. Here is one I used a while back as an example:
http://www.devart.com/dotconnect/sqlite/features.html
To play around with the data, as you would with MySQL Workbench, there are many front-ends. As an example there's a pretty good firefox addon for this:
https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/
And don't worry, it's extremely easy to use and most of the query syntax will apply to MySQL as well!
Complete newbie question here: I'm just playing with C# for the first time and want to make a Windows Forms application which stores some info in a database structure, but obviously don't want to require something like MySQL to be installed on each client's computer. How do I go about this?
You can use SQLite. It doesn't require any installation or server on the client's computers. Here is an blog describing how to use it with .NET. It is easy to use, just add a reference to the System.Data.SQLite.dll.
Here is an open source data provider for .NET: System.Data.SQLite
From homepage: "SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain."
You use a database that doesn't require an install. There are a few out there - there's Microsoft SQL Server Compact, which frankly is badly named, as it won't support the more useful SQL functions like stored procedures, views and so on. There's also VistaDB which does support stored procs, but requires purchase if you want Visual Studio plugins.
The answer is Embedded Databases. You've got quite a large list of Embedded databases that you can use:
Commercial:
VistaDB - This database is written completely in managed C#.
Open Source:
Firebird - .NET Driver
SQLite - .NET Driver
You could write your data to XML files, or you could take a look at the Sql Server Compact Edition.
You could also work with objects and serialize/deserialize these to disk as binaries.
Of course the type of storage you choose depends a lot on the kind of data you're storing (and the volume of it).
Use SQL Server CE
An easy way to do it from .NET 3.5 onwards is to store your data in XML files and use Linq to XML. This allows you to use SQL-like commands on your data which are actually compiled into your application, so you get full IDE IntelliSense support and error checking.
Perhaps you could serialise a dataset and save it as XML. I'm a little confused why if you're playing around you would need to install MySQL on all client's computers. You could look at using SQL Express which is free perhaps?
Serialise Dataset:
http://blogs.msdn.com/yosit/archive/2003/07/10/9921.aspx
http://msdn.microsoft.com/en-us/magazine/cc163911.aspx
The Easiest way will be SQL Server Compact, Because it integrates directly into the Visual Studio IDE (I'm just hazarding the guess here that you use VS). Add the "Local Database", Create your tables and be sure to make your Table Adapter with Select, Update, Insert and Delete methods. If during Database Creation you called your Dataset "DS" you will be able to instantiate a Table Adapter Object from
DSTableAdapters
Namespace, and Use GetData() or Fill() methods to retrieve your Data, and Insert(), Update() and Delete() to Manage it.
VelocityDB works in a server less mode but can also be combined with a server when there is a need for it. It outperforms all the other choices mentioned here by roughly a magnitude, see comparison here. It allows you to use almost any .NET data structures persistently. The entire database engine and the optional server is implemented using C# code.
I asked a question a while ago about which local DB was right for my situation. I needed to access the DB from both .NET code and VB6. The overwhelming response was SQLite. However, I decided to pass on SQLite, because the only OLE DB provider for it charges royalties for every deployed copy of my software. It also requires an activation procedure to be run on every single PC.
After evaluating other options (SQL Server Compact edition - barely functional OLE DB provider, Firebird - don't want to have to pay for another driver, etc...), I've come to conclusion that the only viable choice is using .MDB files created by Microsoft Access (or the Jet engine).
I haven't used it since late 90s, so I have the following questions to those who have experience with it.
Have they resolved the problem where the database would corrupt every now and then.
Is access to the MDB from c# accomplished via the ADO.NET OLEDB Provider or is there a native solution (i can't seem to find it).
Is there a viable alternative to the really crappy SQL Editor in Access?
Thanks.
Rather then going "back" to Access, I'd stick with SQLite and use the System.Data.SQLite provider for SQLite data access within the .NET code.
Then I'd just create a simple COM interop .NET class for use by VB6 that wraps any required SQLite data access functionality. Finally, just reference and use it like a standard COM object from your VB6 projects.
My knowledge of Access is probably a bit dated and biased by bad experiences, but within reason I would try most other options before resorting to the Access route.
Have you considered SQL Server 2008 Express Edition (as oppose to SQL Server CE)?
1) Personally, I found that most times that Access DBs corrupted it was due to code that didn't clean up after it self, or there was a faulty Network card involved.
2)
string connectionString = #“Provider = Microsoft.Jet.OLEDB.4.0; " +
#"Data Source = C:\data\northwind.mdb; " +
#"User Id = guest; Password = abc123”
using (OleDbConnection oleDbConnection = New OleDbConnection())
{
oleDbConnection.ConnectionString = connectionString;
oleDbConnection.Open();
...
}
3) SQL Server 2008 Express Edition
MDB corruption is largely due to failures that occur in client machines, file servers, and networks while the database is open. If you put the MDB on a file share this is always a risk, if on a local hard drive and used by one user the problems are much rarer.
I would not expect SQLite to be any different, and if anything worse.
Periodically running JetComp.exe (a Microsoft download) will fix many problems and compact index tables and such. Backups are important no matter what you use.
You don't need MS Access at all to use Jet MDBs. There are some 3rd party tools for designing the database schema and doing interactive queries, both command line and GUI.
Since the MDB format is more or less deprecated, your late 90s knowledge is quite up to date. See this MSDN page
You could also try SQL Anywhere it runs on various OS and has a small footprint. Works for me :)
AngryHacker asked:
Q1. Have they resolved the problem where the database would corrupt every now and then.
Er, what?
There was never any corruption problem in properly engineered apps properly deployed in properly maintained environments. I haven't seen a corrupted MDB in 3 or 4 years, and I have dozens of my apps in full-time production use by many clients in many different types of operating environments.
I think that most people who experience corruption are those who try to share an MDB file among many users (whether split or unsplit). Since you're not contemplating using Access, that's not really an issue.
Q2. Is access to the MDB from c# accomplished via the ADO.NET OLEDB Provider or is there a native solution (i can't seem to find it).
The native solution would be DAO, but that's COM, so you might not want to use that. From C#, I'd say OLEDB is your best bet, but that's not my area of expertise so take it with a grain of salt. I believe that Michael Kaplan reported that the Jet ADO/OLEDB provider was thread-safe, while DAO is not. This doesn't mean he recommended ADO/OLEDB over DAO, though, but his comments also came in an Access context, and not C#.
Q3. Is there a viable alternative to the really crappy SQL Editor in Access?
Why would you be using that when you're not actually using Access? You could use any SQL editor you like as long as you test that the SQL you write is compatible with Jet's SQL dialect.
I, for one, don't see what the issue is with Access's SQL editor (other than the inability to set the font size), but then, I write a lot of my SQL using the QBE and don't ever even look at the SQL view.
To answer your question regarding the really crappy SQL editor in Access - I wholeheartedly agree. The font stinks, MSAccess always badly reformats the query, it sometimes adds in metacharacters that break my SQL, and lastly but worstly, if it can't parse the SQL, it won't let you have access to it!
My solution is to use external code. I use DAO to instantiate MSAccess and can then directly edit the queries using the QueryDefs collection. It lets you do most things - create, rename, edit, etc. There are a couple of things you cannot do this way though - for example, you do not have access to the query metadata (description, hidden, etc).
External code is also great because you can build a suite of test cases, specifying expected return values, etc.
I have a C# application that's utilizes MYSQL. I'm at a beta release point and need an installation package that includes my application, along with MYSQL. So basically, I need to install MYSQL and perform a restore from within my .NET install package.
Any help would be greatly appreciated.
Step 1: You're doing it wrong
You're attempting to install the mysql server. This should be your first clue that something is wrong. Most server apps are designed to be installed on servers, not on clients. The notable point in this is that server apps like to assume that they 'own' the server. This is a giant no-no for client apps.
Step 2: Make a decision, now that we are properly informed
Now that we've established that we're doing it wrong, we need to choose what to do. We have 2 options:
Switch away from MySQL to a 'client' database such as SQLite or SQL Server Compact Edition.
Hack around the problems of installing the server app.
I personally would recommend switching to SQLite (or similar) as soon as possible. It's the "right thing" to do, and you won't have to be maintaining hacks for years to come.
Step 3: You'll want to hack MySQL anyway because it probably seems easier.
You have been warned. Here are some of the things you will need to be aware of, and mitigate:
MySQL wants to install into program files\mysql. If the user already has MySQL installed themselves. You'll break everything
You'll need to tell your version of MySQL to install into a custom folder. I'd recommend it as a subfolder of your application
MySQL wants to run as a service (and the service will likely be called 'mysql'). Again if the user already has mysql, you'll break everything.
You'll need to run your service under a different name
The MySQL server will likely want to write files to Program Files\etc.
You'll need to change it's configuration so it writes to %APPDATA% and so on
MySQL will assume it is always being run by the same user. If you have 2 users on the machine who want to use your program, you'll need to hack accordingly, by either running MySQL as a local service account (security flaws ahoy), or by installing a seperate mysql for each user.
So with all this in mind, I'd say your best bet is to set up an xcopyable mysql
I've post the answer on another question
We took a different approach on this. We make MySQL xcopy-able, by writting a wrapper to generate the configuration file before calling MySQL (to correctly setup the base path and so on). Then we have another service installed using the standard setup. This service will take care of starting MySQL and other required background program (in our case Apache) for us. Since the MySQL is deploy by us, we wanted to have full control over it.
So with this method, you could simply include the MySQL package along with your installation, and just worried about installing your own service.
If you're using, or can use, NSIS, you should read this: Silent MySQL Install
Regarding the restore, you might be able to script something up using one of MySQL's included utils or modify part of this old NSIS script
Good luck!
This question is very similar to another question. However, the answers don't really help.
You can run executables from a custom action in the .Net deployment project, that's what I'd recommend. (Look under the heading "Calling an executable as a custom action")
Hopefully everything can be taken care of by via the command line. If not, try a scripted installer like Wise or InstallShield, I think they have better support for stuff like this.
Hope that helps!
#Orion Edwards
Thanks a lot for the steps. I was having the SAME doubt. In fact, We just turned SQLite down because our standalone application needed some procedures and foreign key contraints.But now I feel SQLite is always a better choice for standalone desktop application if it is do be deployed on client machines.
For now,I have to stick to MySQL. So I'm using different kinds of scripts and mechanisms to handle different possible situations. Eg:
If the client machine has no mysql pre-installed, there is a script which completely installs the server and creates the database, users required for my application.
If mysql is pre-installed on client machine, I'm asking user for mysql's root username and password and setting up the database & users from within the apllication.
And thirdly, if for some reason client machine had mysql server earlier and then it was uninstalled, since mysql DOES keep track of previous root password even after uninstalling,I run mysql server's .msi, reset the password (manually carry out some steps), and finally create instance of database, all within a script (of course these steps are needed to be carried out by US, not the user as this is a very rare case.)
Is this approach OK? Or there is a better,appropriate way to do this?
In future I think i'll stick to SQLite! :-p
Have a look at using Visual Studio's package and deployment tool. It should automatically bring in the MySQL dependencies if you connect natively (MySQL .NET components) rather than an ODBC connection. In any case it allows you to add other software to an installation program that can be automatically unpacked if you need it. I have used it to deploy C# apps using the MySQL libraries that you download from MySQL website and for CoreLab's MySQL 3rd party libraries.