Just wondering if any Firebird users can confirm that batched queries is not a supported feature in the current release (2.5) and if anyone knows if this is in the pipeline for a future version?
We use NHibernate as an ORM in our C# application and would dearly like to make use of the "Futures" feature to combine the execution of multiple queries into one request sent to the server. We've discovered that this feature isn't available as our queries "fallback" to one request per query instead of batching them.
I know Firebird has an "EXECUTE BLOCK" statement which effectively creates a virtual stored procedure but it doesn't seem possible to implement this with any of the current .NET providers for Firebird. Is anyone using Futures with Firebird? Firebird is a great database, free and can be implemented as client/server or embedded ... I mean there's not much that Firebird lacks except support for batching queries.
Any experts want to add their opinion?
Firebird itself does not support query batching. This could be simulated in the driver (this is wat the Firebird JDBC driver Jaybird does), but as far as I know the .NET provider for Firebird does not provide this feature.
Firebird 4 will introduce support for batched queries in its protocol, but drivers like the Firebird ADO.net Provider and Jaybird will need to implement support for this.
Related
Is there any NON-GPL ADO.NET provider for MySQL ?
There is the official one from here
http://dev.mysql.com/downloads/connector/net
but unfortunately, it's under the GPL, not the LGPL.
I am developing an abstract class for database access.
I don't care whether the abstraction layer is going to be GPL,
but if it uses MySQL (I mean the MySQL ADO.NET provider, not the MySQL database itselfs) it will be GPL, and thus, any application that uses that layer, which is something I don't want...
Oh, and I know about nHibernate/Subsonic/otherORMs, but it doesn't fit my needs.
ADO.NET provider short of using ODBC of course.
Edit/Clarification:
Note that by "abstract class for database access", I don't mean write my own universal ADO.NET provider.
I mean writing a wrapper class around a set of already existing ADO.NET providers.
I got the perfect answer:
One can use System.Data.Odbc to get around it.
You can always say, it's generic ODBC, has nothing in particular to do with MySQL, easily replacable.
And whatever you put in the connection string is the problem of your customers.
If the SQL that you send over the ODBC connection works in MySQL/MariaDB only, that's regrettable - but no legal problem ;)
Edit - 2016 Update:
You can use the MIT-licensed MySqlConnector for .NET Core (which also works for .NET)
https://github.com/mysql-net/MySqlConnector
There is DevArt's ADO.NET provider for MySQL
http://www.devart.com/dotconnect/mysql/
Stop swallowing the Microsoft FUD.
This is covered by v2 of the GPL therefore, unless you intend to modify the supplied code and redistribute it (as opposed to bundling it with your own application) your only constrained in that you need to state that the bundle includes GPL v2.0 licensed code and reference the copyright owner (which you are nearly always required to do with most commercially licensed software anyway).
but if it uses MySQL it will be GPL
Ah - no. You can program it ina way it does not even KNOW it connects to MySql.
Isolate all abstractions into a separate assembly.
Implement your propietary interfaces in this (allowed).
Distribute the abstraction of mySql as gpl.
Finished.
I want to develop a multiuser supporting accounting management application in C#.
I want to use Linq To SQL classes. LINQ to SQL only supports SQL Server/Compact. However is it possible the SQLite people have written their own LINQ provider given the name of the assembly.
I have to use DBMS that is FREE. Which DBMS do you suggest to me?
LIN2SQL = SQL Server. Second class badly written O/R mapper compared to the real contendors (like NHibernate).
LINQ2SQL != LINQ. LINQ is the query integration into the langauge, and supported by pretty much a lot of O/R mappers out there, and some databases.
I have to use Db that is FREE.
Free like for free? What is against sql server? Express edition - 0 USD. And the 4gb "database size limit" does not stop you from writing accounting systems. THat is a LOT of space for accounting data. For many years of accounting data.
If you want to use Linq-to-SQL (which I think is an excellent choice) you have to use some variant of MSSQL. Both Sql Server Compact and Sql Server Express are free to use. If you have a multiuser scenario you will have to go for Sql Server Express as Sql Server Compact doesn't allow multiple simultaneous access.
There are various experimental linq to sql and linq to entity framework providers for other databases(like mysql and postgres) - in my experience they are so immature it is not worth using for anything serious.
For now, I'd suggest you'd look for something else if you cannot use SQL server.
Try the following link:
http://sqlite.phxsoftware.com/
Note that Linq2SQL is not compatible with SQLite, however the link points to an Entity Framework provider for SQLite. EF is kind of like Linq2SQL on steroids. SQLite is very lightweight, so the EF implementation above should work nicely for your needs.
I have not done database programming in C++ and C# before, but did some in Java. Now I am asked to figure out the options to do it in C# or C++ (not sure which one yet). We may use the MySQL RDBMS.
I searched online and found .NET SQL Data Provider, OleDB and ODBC.
What other APIs exist?
What's your recommendation?
Do I need to buy separately?
Are they API can be used directly?
There is also a data provider in .NET for Oracle if you want to consider that.
The following data providers are actually included in .NET
OLDB
OLEDB
Oracle
SQL
You can start using these by including their namespaces and working with the relevant classes. You can also work easily with XML in .NET using the in-built classes. If this is your first time working with data in .NET I would strongly recommend reading up on ADO.NET and LINQ.
You can download MySQL connectors for .NET from the MySQL website: http://dev.mysql.com/downloads/connector/net/6.1.html.
Connectors to other DBMSes can be found on the database providers website. Some come pre-installed with Visual Studio.
An earlier question about C++ ORMs.
As for C#/.NET, there are native providers, the OLEDB provider, and ODBC provider. There are native providers for MySQL, PostgreSQL, MS SQL Server, Oracle, etc. The programming model is the same if you use the IDbConnection, IDbCommand, etc. interfaces.
If you don't want to write all the code yourself - iBatis.NET, Subsonic, NHibernate, etc. are good libraries to look at.
I have a simple app written using SQL Server, Entity Framework, C# and WCF. When I wanted to share this app with my friends, I realised they didn't use SQL Server on their machine. I could go for SQL Server Express edition, as the usage of my app is personal and non-commercial.
I found MySQL as a popular alternative to SQL Server.
1) Would I be required to update my entities when moving to MySQL?
2) Should I anticipate code changes in my BL layer due to change in entities layer? (I am wondering whether entities was built for SQL Server)
Are there any databases similar to MS Access that is lightweight compared to MySQL?
Are there any databases that need not be installed but can be copied around like MS Access?
Appreciate your response!
Sounds like you want SQLite.
SQLite is a software library that
implements a self-contained,
serverless, zero-configuration,
transactional SQL database engine.
Very easy to deploy. Also, check out System.Data.SQLite.
According to the System.Data.SQLite page ...
Supports nearly all the entity
framework functionality that Sql
Server supports, and passes 99% of the
tests in MS's EFQuerySamples demo
application.
You should be good. :)
Im not sure how your BLL looks like and i have no experience with entity framework, but ive experienced multiple times that linq-to-sql works much better with sql-server as with any other database.
So unless you have a good reason not to use sql express, i'd advice to stick to sql express.
After all, you should always install something when deploying (unless you use xml as storage, which is quite well possible with linq-to-xml).
VistaDB Express Edition is also free for non-commercial usage and integrates good into .NET and VS. afaik it also works on a single local data file thus requires no specific installation on your friends' computers.
Otherwise I recommend using PostgreSQL over MySql since it is more standards compliant and has a nicer license.
I think what you're after is just a change in providers. What you need to use MySQL is the .Net Connector which supports most everything simple. It's not very mature yet so something very complex you may have issues on, but it should do most of what you want through Entity Framework.
With Entity Framework yes you can do updates, it's LINQ-to-SQL that doesn't update against any other databases (unless you use a third party provider like DotConnect)
SQLite is one alternative, but since multiple threads against it can cause major issues with it's operation, so if you need a major data store I'd go SQLExpress or MySQL.
Yes, you could use MySql with EF but I don't know if it would require changes.... I wouldn't be surprised if it does though. At the very least your physical DB would have to be ported / converted to MySql and that will take time.
I would assume that if you need to install a DB on your friends Pc's why not stick with SQL Express since you already developed in SQL Server on your box. Should be less issues with this than migrating to MySql.
I'd also vote for VistaDB 3 as it's so easy to deploy.
There are numerous libraries providing Linq capabilities to C# code interacting with a MySql database. Which one of them is the most stable and usable on Mono?
Background (mostly irrelevant): I have a simple C# (.Net 2.0) program updating values in a MySql database. It is executed nightly via a cron job and runs on a Pentium 3 450Mhz, Linux + Mono. I want to rewrite it using Linq (.Net 3.5) mostly as an exercise (I have not yet used Linq).
The only (free) linq provider for MySql is DbLinq, and I believe it is a long way from production-ready.
There is also MyDirect.Net which is commercial, but I have heard mixed reviews of it's capability.
I've read that MySql will be implementing the Linq to Entities API for the 5.3 version of the .net connector, but I don't know if there's even a timeline for that. In fact, MySql has been totally silent about Entity Framework support for months.
Addendum: The latest release of the MySql Connector/Net 6.0 has support for the EF according to the release notes. I have no idea how stable/useful this is, so I'd love to hear from anybody who have tried it.
According to the Mono roadmap I'm not sure if Linq is available for mono?
At least some of Linq might be available in the very latest release, but Linq to DB is listed for Mono 2.4 (Feb 2009)
Not sure about Mono, but I just started using LightSpeed and that supports LINQ-to-MySQL.
at this time you cannot use linq to sql, you might look into a third party linq mysql provider or linq to entities. linq to sql only works for sql server databases.
LINQ to SQL is simply a ORM layer leveraging the power of expressions to make it easy to construct queries in your code.
If you are just calling adhoc queries for your tool, there is little need to use LINQ, it just adds an extra layer of abstraction to your code.
I have tried the tutorial at http://www.primaryobjects.com/CMS/Article100.aspx. This uses dblinq/dbmetal to generate the data context class and classes for each table.
The code failed at the first attempt with an unhandled exception (MySql.Data.Types.MySqlConversionException: Unable to convert MySQL date/time value to System.DateTime"). Googling revealed this should be easily solved by appending "Allow Zero Datetime=True;" to the connection string.
Unfortionately this turned out not to solve my problem. Thinking the MySQL .Net Connector was to blame I executed the SQL generated by dblinq without the linq2sql intermediary layer using the MySQL Connector. This time no exception occured.
Tables which do not have a date column did work with DbLinq.
So, from my experiment I agree with Adam, DbLinq is a long way from production ready.