Quote:Original post by Flimflam I would advise a word of caution using Access, as I have run into issues from machine to machine, depending on the libraries they have or even the versions of Access they have (if they have it).
According to Microsoft that problem is solved if you use their packager that comes with the redistributable Access Toolkit. It also apparantly contains the source code so you could probably decipher how to solve the problem on your own. So if thats the only reason not to use access it seems like MS has long since solved it.
You could try SQL Server Compact Edition (formerly SQL Server Everywhere). It's an embedded database (just like SQLite) so the only thing you need to deploy are the runtime DLLs (just like SQLite), but it gives you access to a large subset of the functionality of the real SQL Server. See here for an introduction to using it.
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
You do have to pay for licensing per copy for DISTRIBUTING copies of MySQL with your game. If your game is online and is only used to store data (the client you distribute commercially has no actual MySQL binaries in it) online, then it's free to use. That's why websites which use MySQL dont need a commercial license. A client accessing backend data is also under that.
A game that installs MySQL and uses it to store data on someone's machine requires a commercial license.
Quote:Original post by Arild Fines You could try SQL Server Compact Edition (formerly SQL Server Everywhere). It's an embedded database (just like SQLite) so the only thing you need to deploy are the runtime DLLs (just like SQLite), but it gives you access to a large subset of the functionality of the real SQL Server. See here for an introduction to using it.
SQLite.NET really looks good, but unfortunately it does not specify what the code license is. Obviously it's an open source one, but which one? zlib? gpl? bsd? Without such information (which can surely be obtained from the author), I would advise to not use it.
Of course, the best thing to do is probably to contact the author and to get the answer (and the formal authorization to use it in your product if possible). This should not take long, and would probably save you some headaches.
As your primary constraints are "fairly data-centric", "distribute", and "need to use C#", I wonder why you don't consider Berkeley DB for .NET (found on Sourceforge).
From what I understood, you only looked into SQL because you happen to know SQL quite good, but you don't necessarily need it.
Berkeley DB is not SQL, but it's a database, and it is quite good for "fairly data centric" applications. The "Berkeley for .NET" package is BSD licensed, so there should be no objections to use it in a commercial application. In any case, it has only around 5% of the bloat that you'll have to face with shipping a Microsoft SQL engine.
First of all I'm not sure that a data-centric game necessarily requires SQL-style functionality. One of the few cases where transactions are important enough would be MMO-style games, but in those cases I'd worry a little more about the database itself and a little less about the .NET interface. If there is some specific database functionality you are looking for then this will obviously also help eliminating options. What exactly is it that you need, and why do you need ADO.NET and .NET 2.0 Data Binding?
It's quite possible to use a database during development without actually having to integrate it or some lightweight alternative in the game itself. This could be both easier and faster in the long run.
Quote:Original post by Erik S. Andersson . What exactly is it that you need, and why do you need ADO.NET and .NET 2.0 Data Binding?
Nobody NEEDS ADO.NET or .NET 2.0 Data Binding. For that matter nobody really NEEDS C# itself either. You can do things the "hard way" or the "old way" if you want to call it that.
Specifically the requirement for Data Binding revolves around creating the game editor which allows you to basically alter every aspect of the game. It is a lot easier to write and update this interface using data binding.
SQL has quite a few advantages for doing complex data retrieval operations, but whether it is needed or not would, I suppose, depend on how much work you want the DB engine to do. If your queries are all like "SELECT * FROM sometable WHERE sometable_id = 6" then you don't need SQL at all. If, on the other hand, you are going to write complex queries, with joins and aggregate functions, then SQL is a lot betterr than having to code your own operations.
Does the Berkeley DB have a SQL engine or some equivalent available, also? If so, then that would be a great choice.
Nobody NEEDS ADO.NET or .NET 2.0 Data Binding. For that matter nobody really NEEDS C# itself either. You can do things the "hard way" or the "old way" if you want to call it that.
Specifically the requirement for Data Binding revolves around creating the game editor which allows you to basically alter every aspect of the game. It is a lot easier to write and update this interface using data binding.
Of course you don't need anything in that sense, but the question was more if the requirement came from someone else or if it was a personal preference. Although I have no personal experience with ADO.NET/Data Binding I'd still say that it is highly unlikely that anything else is to be considered hard and antiquated. As far as I can tell you want to use your previous experience in SQL on the game which might be a good idea, but it might also make things more complicated than necessary. I'm genuinely curious, what about data bindings makes everything else look old and hard?
