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.
Related
I work for a company that uses a program that uses Foxpro as its database.
I'm actually a little bit confused if Visual FoxPro is just a DB or its a programming lagnauge + database combined.
I want to create some software to integrate with it, but I just need to manipulate the date in the database (As i do not have access to the source).
Is there a SQL Management Studio equalivelent to Visual FoxPro, and can I see the tables and data by looking at the Database files? or is it all integrated some how into the programming and I would need the source to manipulate it?
The best SQL Management Studio equivalent would be the VFP IDE. However, as a C# developer you might prefer to use LINQPad so that you can work with the data using LINQ and not have to know anything about the VFP syntax. As far as writing some C# code to manipulate VFP data… I would suggest checking out LINQ to VFP and the VFP EF Provider.
Full disclosure: I wrote the LINQPad Provider, LINQ to VFP, and the VFP EF Provider so I might be a bit bias :)
Visual Foxpro is both a programming language AND a database all wrapped into one. If you can get Visual Foxpro, you can do you own programming and directly work with opening the tables, updating them, etc as you need.
Additionally, Microsoft has an OleDbProvider that can hook up to VFP tables and do all your common select/insert/update/delete functionality too. So, that said, you can use whatever .net you might be comfortable with. I personally use C# and the Microsoft OleDbProvider and have built some websites with it and also desktop apps too, all going directly to the tables. The only issue is IF any of the tables are encrypted using a third-party encryption tool.
I and others have had many posts on how to connect with VFP to select, insert and update data, so you can obviously feel free to look that up. I would start by using tag search such as
C# VFP OleDb
And you'll always be able to ask again here to get answers when you get stuck :)
Without FoxPro itself (think access) you are messing about with ODBC and writing it all yourself. or better yet (apparently) there's an OLEDB provider for it.
Sm OLE DB Provider for Visual FoxPro
and like #Tim Medora, I'm sorry.
No need for anyone to say 'I'm sorry' and as Alan B said, there are more FoxPro apps out there than most folks will ever realize. I for one have made a good living out of converting MS Access apps to FoxPro due to Access cratering with large data files.
FoxPro is both a Database (Think RDBMS systems) and a great rapid application development tool. You can easily read the tables through the OleDbProvider, and if you're using it as a front end you can easily connect to ANY of the main Databases. I personally have apps that connect to MySql, Sql-Server.
Writing an application in C# to read and return the data in FoxPro tables is actually quite simple if you're using Visual Studio 2010 and Tom gives some excellent links for info on how to accomplish what you're trying to do
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.
In this program I'm writing, it would need frequent database communication, and at the moment I'm using just XML files. Is there really a benefit from using MySQL or SQL in general over XML. Just note that I'm using C# so MySQL is not very fun to deal with in it (from what little experience I have).
In terms of maintaining data stored in XML files vs. a relational database (Mysql, in your case), the database is far more robust than simple XML files. But this is simply an exercise in determining the needs of your application.
MySql, like many other RDBMSs, will provide much more than just a place to park your data. The biggest advantage to using a modern db such as MySql is ACID support. This means you get all-or-nothing transactions, ensuring consistency through your data.
You also get referential integrity to ensure that related records stay intact and don't leave you with abandoned references to other data records. We could go on and on to discuss the value of locking or the power of stored procedures.
But really, you should consider the needs of your application. If you do significant gymnastics to keep your data in order or you care about shared access and file locks while trying to read and write data, you need to punt on your XML file basis. No need trying to find ways around these issues when a basic mysql database will solve those issues.
If there's truly relational data...you'll almost always benefit from using a RDBMS. Retrieving data will be faster with the backing of a query engine rather than tying together XML nodes. You'll also get referential integrity when inserting data into the structure.
There is an ADO.NET provider for MySQL, so you shouldn't have any more difficulty dealing with a MySQL database than MS SQL Server.
You could even download DbLinq and give their LINQ to MySQL functionality a shot. Could make things even easier (or you could use Entity Framework with the MySQL ADO.NET provider).
The size of XML documents can be a large factor. In XML you either produce large and complicated text files with a huge amount of additional data or your data is split up accross several files. Managing these files can be a headache. Using a SQL database will allow you waste less disk space.
SQL is faster than using XML.
Any SQL database will give you access to a whole set of permissions and role capabilities that may be difficult to enforce using XML.
If you have relational data, a database would work. As an alternative to MySQL, if you aren't looking for a centralized solution, you can use SQLite. SQLite runs in-process (meaning the program running it is it's own "database server") and requires no installation other than distributing the DLL file containing it.
Robert Simpson has written System.Data.SQLite, a SQLite Data Provider for the .Net framework. It's free and open source (like SQLite) and works and feels as native as System.Data.SqlClient does. It supports standard ADO.Net conventions, Linq, and the Entity Framework.
I've used System.Data.SQLite for projects at work for applications that need to run fast and cache data locally for comparison between multiple runs (data processing and job scheduling). Firefox is a good example of an application using SQLite, Firefox 3 uses SQLite for it's Cookies, the Downloads history, Form autocomplete, and most importantly your web browsing history.
Again SQLite is meant for direct application use and lacks features like user authentication and schema permissions. It has issues if multiple programs try to write to the same database (those can be worked around but nothing like what a real RDBMS can do). It's biggest advantage is it doesn't need to be installed and set up to work like MySQL does. In the C# case all you have to do is reference System.Data.SQLite and copy the .dll file along with your program and it'll work.
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'm in the early stages of a project, and it's not clear yet whether we'll need a "real" database (i.e. SQL Server et al). So I've been doing some prototyping using MS-Access, which is working fine so far. (developing in C#/VS2008/.Net 3.5/MS-Access 2000).
However, the object-relational impedance mismatch is already becoming annoying, and will only get worse as the project evolves.
I have not been able to find an ORM that will work with MS-Access. Any suggestions?
Edit - Follow Up
We ended up using Fluent NHibernate, mainly because it Automaps our object model to a relational database, which has been a huge win for us. Most of the FNH code samples we found used SQLite, and this worked so well that we intend to use it for our production database. (The app is a desktop scientific data collection and analysis package).
MSAccess files can be set up as an ODBC source on Windows machines. Almost any ORM will allow you to use ODBC. Here is a quick tutorial on how to set that up, it's outlined for Win2k but the process is the same for XP+. You also need to have MDAC installed on your box.
NHibernate seems to have native support of MSAccess as well, see here. I've never used it though. It also has an ODBC driver.. Many others support ODBC as well.
And again, as others are saying.. MSAccess does not scale... period. Installing a real database server is fairly easy, so I'd recommend SQL Server Express as others have, or even MySQL or Postgre, whatever is easier to set up.
If this is an application that you intend to deploy to clients, with each client having their own unique database, I would recommend another solution entirely, SQLite. SQLite gives you database power on an app by app basis. If you have a central database server, one of the previously mentioned solutions would be best.
There's only one scenario when choosing the Access Database Engine is a good choice: when building a self-contained Access application using Access Forms (though choosing to use Access in the first place is a questionable choice ;)
The database engine that VS2008 plays nicest with is SQL Server and you will have no problem finding an ORM that plays nice with SQL Server.
Can't give you an answer to your question, but instead of Access you might want to consider one of the following options:
SQL Server Express: is free and compatible with the full SQL Server
SQL Server Compact: also free, does not require any deployment/installation, does not support all features (e.g. no stored procedures).
At this stage, if you are unsure whether you need a "real" database or not, I'd skip MS Access and go straight to sql server express. It's free and still allows you to do everything you need to.
Plus, if you later decide you need to scale up, then you can without any pain.
I recommend you to use something like Microsoft SQL Server or PostgreSQL for prototyping. If you don't want to learn specific SQL syntax and install special tools for designing database schema, you can use ORM that automatically generates database schema from your persistent classes declaration. Anyway this approach is very effective for prototyping.
LLBLGen works with Access
Access is just a bad, bad idea. I believe MS only includes Access in Office to keep legacy users happy.
Even if you find an ORM that will work with an Access database, with few exceptions you're locking yourself into a niche tool that likely will not work out-of-the box with a real database engine. If you decide to switch to a real database engine later on, you'll not only have to deal with migrating the database, but switching to a different ORM.
See this comparison between SQL Server Express and SQL Server Compact. The comparison document also mentions some problems with other data stores, including Access.
If you are REALLY concerned about being able to install SQL Server Express, consider SQL Server Compact:
it can be linked into your redistributable app. No need to install a service (which may require admin rights during install of your application); everything is taken care of when you install your app. This makes the most sense if you need the data to reside on the user's machine instead of a server, and is most analogous to using Access.
It's less powerful than Express (doesn't support views, triggers, stored procedures, which I consider a requirement)
Can be scaled up to Express or other SQL Server versions very easily
Suitable for small-footprint installs like tablets, mobile devices, etc.
Always keep scalability in mind when designing any application. You don't want to wind up having to write a PHP->C++ compiler if/when your app becomes successful just because you picked the wrong tool up front.
While we're at it:
The big issue with Access (or, in this case, the Jet engine, which is the part you'd really be using when integrating an Access database with a .NET app) is that there is no "server" that handles datase requests. The engine, hosted in your app, must read and write directly to a file on disk that contains the database. Whenever this happens, the file must be locked to prevent concurrent writes. Dirty reads become more common as the number of users grows, as does the potential for database corruption.
Imagine having every customer at a large restaurant trying to simultaneously enter the kitchen to write down their orders or retrieve their food. Chaos would result. There'd be a lot of broken dishes, the kitchen would be a mess, you'd be lucky to get what you ordered in any sort of edible condition. With one customer, this probably works fine. With 5, eh, maybe. With 20,50,1000? Not so much.
So, the restaurant industry introduced waiters and managers that buffer IO to the kitchen. The database server application does something roughly analogous to this by restricting access to the files on disk. Everyone gets what they want, faster and in a much more reliable way, and the data store is protected.