I'm trying to call a UDF using Entity Framework and I was wondering:
if I a use a different provider (LINQ to MySQL, LINQ to PostGreSQL) will it still work?
I've searched the SQL Standard and it's not freely available.
UDF implementations and rules are significially different in MySql, MS SQL and Postgresql. So really the first question is, can you migrate any UDF easily between this DBMSes? Generally, you cann't if you didn't created this UDF to be transferable from the very beginning.
Related
I have a project where the PERIOD columns defined in the SQL2011 spec are the perfect solution. Unfortunately, I am forced to use MSSQL 2008R2 (or possibly MSSQL 2012) as my database, which does not support this feature.
Is there any proprietary feature that resembles the PERIOD features in SQL2011 currently in MSSQL? If not, any advice for the best way to try to implement something resembling it?
Take a look at Anchor Modelling. I know it's not exactly what you're looking for, (a PERIOD equivalent) but databases implemented as an Anchor model can include bi-temporal aspects. The generated SQL code when exporting the model primarily supports MS SQL. Oracle is available too but a lot of work when into optimizing the schema, trigger and view SQL code for MS SQL. Maybe it'll help, maybe you can see how they implemented bi-temporal data in a way that works really well with MS SQL.
I'm looking for a SQL Implementation (and its Editor) that can be used for translating it to many other(s) SQL Languages.
For example, when i code in that SQL Language to script file(s), and then i translate to other(s) SQL Language script file(s) (for ex: MS SQL's , MySQL's , ...).
If you're sure to use only ANSI SQL to construct your scripts, you should be good to go.
I agree with #Justin Niessner: all SQL vendors pay attention to the SQL Standards, notably core SQL-92. To take SQL Server as an example, although they find Sybase legacy code is tricky to deprecate they are not afraid to do so and entirely new features (e.g. MERGE in MSSQL2008) tend to extend their Standard SQL equivalents, rather than reinventing the wheel.
For a product that has good Standards compliance, take a look at Mimer
Here at Mimer Information Technology, we pride ourselves on conforming
to the SQL standard and we play an active role in the Database
Languages standardization group which determines exactly what is SQL
standard.
Mimer also provide extremely useful SQL validators for SQL-92, SQL-99 and SQL:2003 respectively.
I've been researching the same thing a while ago. What I've found is that there is a project liquibase. It is aimed at change tracking but also converting between different DBMS. You can download source code and see different datatypes conversions across databases. Source at github browse for java files there, probably you'll find something helpful
If all you want are basic operations, these are fairly universal. For instance:
SELECT
INSERT
DELETE
UPDATE
FROM
WHERE
JOIN
...are all at the most basic level the same across implementations.
However, the more complicated your scripts get, the more difficult it becomes to make them "universal". Things like aggregation, subqueries, cursors, while loops, functions, indexes, constraints, temp tables, variables, string manipulation, window operations etc. are all pretty much database-specific.
Some of these do have "universal" equivalents but the more generic you make your code the worse it will perform.
I am working on an application that will need to communicate with many different applications running on different database platforms. I will know the table schema before runtime but I won't know the database platform (MS SQL 200X, Oracle 9i, 10g, etc, MySQL 4.0.1, 5.x, etc, sybase, etc) until runtime.
It's my understanding that each of these systems have a slightly different dialect. Do I need to use nhibernate to handle the differences when connecting to these systems or can I use ADO.NET and pass raw SQL strings (select * from table)?
If you only need to use ANSI SQL statements, which should be implemented by all of the databases then yes, you can just use ADO.NET.
In my experience the main problem with database-agnostic code is the use of surrogate keys, like sequences or autonumber fields, as all databases implement these differently.
If you do need to use features that differ across databases then I don't think that it is reason enough to go to an object relational mapper like NHibernate - only do that if you have other reasons to do so. You can implement your own handling of syntax differences by generating different SQL for different databases easily enough.
SQL should be standardized for all dbs but they don't all use the same syntax so it really depends on what SQL you're calling. For example, SQL Server uses TOP while Oracle uses rownum. Even if they're all DDL, some syntactically differences between DBMSes can be an issue.
If select * from table is all you want, then there shouldn't be a problem, other than performance hits.
I am creating a quick and dirty prototype (C#) of an object-relational mapping tool. I would like to support at least two kinds of databases - one will be Microsoft SQL Server 2005/2008 and the other most probably MySQL.
Is there any way to use a single data base access mechanism for both database engines and what would it be?
Of course, I know that there will be differences in SQL query syntax, but in my case it is not that important - I'll use a tool to generate SQL queries which suit the certain db engine and user will be able to optimize those SQL queries.
The main idea is to have as flexible data provider solution as possible. Can it be done or not and how can it be done easier?
Note that I am not using this for a production system, just for a prototype, but still I'm curious how it is achieved in production OR/M tools - are they using completely separate access mechanism for each data provider or there are something common? And are they using DataReaders or there is some more appropriate way to retrieve data if I intend to transform data to business objects?
Thanks for any ideas, links etc.
Ok, I found it:
http://www.15seconds.com/issue/040127.htm
the solution is to use IDbxxx or Dbxxx as described in msdn.microsoft.com/en-us/library/ms379620(VS.80).aspx
Now I can specify only once what kind of DataProvider I use and then just use Db/IDb everywhere else.
I recommend nhibernate - which does what you want I think.
nhibernate.info
Are there any free (gratis) providers for databases other MS SQL (e.g. MySQL or SQLite) that work with LINQ and support dynamic SQL query generation? E.g. table.Count() generates something like SELECT COUNT(*) FROM table and doesn't first load the whole table and then count the rows.
Here is the DBLinq project: http://code.google.com/p/dblinq2007/
DbLinq is THE LINQ provider that allows to use common databases with an API close to Linq to SQL. It currently supports (by order of appearance): MySQL, Oracle, PostgreSQL, SQLite, Ingres, Firebird
Whether these providers execute Count() in the way you describe depends on the quality of the provider, I suppose. Presumably some effort is made at optimization.
See also http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
Check out ADO.NET Entity Framework. It supports MySQL via ADO.NET data providers and LINQ to Entities (similar to LINQ to SQL). Being a Microsoft tool, it has good Visual Studio integration and support.
Can you also explain why you want to support these databases?
NHibernate supports multiple databases and has a recently-released Linq provider.