Specify firebird connection dialect, not database dialect - firebird

I have a Firebird database which is using Dialect 1. Some old Delphi apps MUST have it using Dialect 1 or certain queries will fail. The issue is, I'm using ColdFusion to communicate with the database for our web applications and it needs Dialect 3.
Is there some way I can set the dialect at the client connection level? So that my ColdFusion Datasource can use Dialect 3, while the old Delphi apps can still use Dialect 1?
I've tried using the following but it did not work at all.
jdbc:firebirdsql:localhost/3050:C:\fbdb\master25.fdb?sql_dialect=3
and when I did this way, it changed the dialect completely to dialect 3 which broke the Delphi apps.
jdbc:firebirdsql:localhost/3050:C:\fbdb\master25.fdb?set_sql_dialect=3
Any ideas? I'm using the Jaybird JDBC Driver to connect from ColdFusion.
Update
The problem is it looks like things have changed on Firebird 3.0. On our 2.5 database under Dialect 1, we have stored procedures where arguments are declared as date. In Firebird 3.0 under Dialect 1, these stored procedures throw an error stating
Database SQL dialect 1 does not support reference to DATE datatype
When we switch over to Dialect 3, everything works - but then our Delphi applications break due to many of them having direct queries where it selects date type columns which Firebird 3.0 is now treating as TIMESTAMP. So instead of getting back 2018-06-25 for example, we now get 2018-06-25 23:59:59.
If there is some way I can set things up so our Delphi apps can communicate as Dialect 1 where also allowing the ColdFusion Data Source to communicate as Dialect 3, that would be ideal.
Is that even possible?

To answer the question implied by the title (without addressing the specifics of the body of the question): you can specify the connection dialect using connection property dialect (with aliases sqlDialect and sql_dialect), which takes values 1 (legacy dialect 1), 2 (bridge dialect) and 3 (current dialect). Technically 0 (auto-select based on database dialect) works too, but in some cases this causes dialect 3 to be used anyway even if the database is dialect 1. The default is dialect 3.
The above applies to Jaybird 3.0.x, dialect selection with Jaybird 2.2.x and earlier will apply a combination of the specified dialect and dialect 3, so should be considered broken.

Related

Set PostgreSQL search_path in jOOQ

Back in jOOQ 2.5 it looks like you could set the PostgreSQL search_path through the FactoryOperations class, but that class is gone in jOOQ 3.5. Apparently FactoryOperations split into DSL and DSLContext, but I can't seem to find where the use(Schema) method wound up. How do we set the PostgreSQL search_path in more recent versions of jOOQ?
When jOOQ 3.0 was released, some of these "legacy" features were removed mostly because they weren't well thought through. In this particular case, the use(Schema) method pretended that the different RDBMS supported by jOOQ actually had a common idea of what the "current schema" is. The implementation, however, was a bit misleading and confusing to those users that use jOOQ with more than one database.
More information on the jOOQ 3.0 feature removals here.
The solution today is to
1. use vendor-specific commands like
ALTER USER my_user SET search_path = ...
More info about that here
2. use jOOQ's runtime schema mapping feature
Using this feature, you can specify at run time what the real schema name generated by jOOQ will be. For instance, if the schema in your generated code is FOO and the "ordinary" SQL statement generated would look like this:
SELECT foo.table.column FROM foo.table
You can specify a mapping from FOO to BAR to let jOOQ produce the following SQL instead, without touching your Java code:
SELECT bar.table.column FROM bar.table
More info about that here

Is image type not supported in code first configuration any longer?

Using EF4.3 Code First with SQL Server 2008 R2 Express (version 10.0.5500).
I am trying to set the ColumnType property in my model to instruct the database to use the image datatype for a column instead of the default varbinary(max). I have tried using both data annotations [Column(TypeName="image")] and the Fluent API: .HasColumnType("image").
Neither seems to work (although no exceptions generated), the type of the database column remains varbinary(max) after re-creation.
All other configuration seems to work fine.
Is this datatype no longer supported in Code First? It seems to be still supported in SQL Server 2008 R2 Express if I look at the database in SSMS.
Thanks

Transaction wrapped around Enterprise Data Library code + Entity Framework code

Hey I have a unique and troubling situation.
I am working on a project where my team has used a mixture of Enterprise Data Library plus Entity Framework. Obviously this probably not recommended but it is what I'm stuck with. I would like to take a method written using Enterprise Data Library and also take a different method written using Entity Framework, and wrap both of these methods in a single transaction (without requiring Microsoft Distributed Transaction Service). I'm hoping to minimize rewriting code and be able to wrap the two methods in a single transaction just as they are. Is this possible? Thanks.
Using SQL Server 2008 and .NET 4.0
I suppose you want to mix EF and EntLib queries in the same TransactionScope, without using DTC.
Good news: it's possible. If you use exactly the same connection string for EntLib DAAB and EF DbContext, it will work, depending on the versions of EF, EntLib and SQL Server.
So what you have to do is:
check you have the right versions
get the version of your connection string changed by EF and use it instead of yours.
For 1, I have checked these combinations:
SQL Server must be 2008 or older
EntLib 4.1 + EF 5 doesn't work
EntLib 5 + EF 5 works
For 2, to get the connection string changed by EF you have to debug the execution of code that uses an instance of a DbContext. Set a breakpoint and watch or inspect the DbContext Database.Connection.ConnectionString property. That's the EF version of your connection string. Use it for both EF and EntLib and you'll get rid of DTC.

Is there any driver that supports Sybase ASE's Stored Procedures in Entity Framework?

All support I've seen so far is for SQL Anywhere, and sadly, I'm locked to use Sybase ASE 15.5 as well as the Cluster Edition.
All this comes because although I can add SPs to my Entity Model (through Function Import), when I call said SP, it returns nothing, and in the Function Import Window, I can't get the column information because it throws a "System.NotSupportedException".
I'm using Entity Framework 4.1, Sybase ASE 15.5, the SDK 15.5.0.1000 and Visual Studio 2010 on Windows 7 if that matters.
We had a similar issue. So, we choose to go with Progress Data Direct Provider

EF4, self tracking, repository pattern, SQL Server 2008 AND SQL Server Compact

I am creating a project using Entity Frameworks 4 and self tracking entities. I want to be able to either get the data from a sql server 2008 database or from sql server compact database (with the switch being in the config file). I am using the repository pattern and I will have the self tracking entities sitting in a separate assembly.
Do I need two edmx files? If so, how do I generate only one set of STE's in the separate assembly? Also do I need to generate two context classes as well? I am unsure of the plumbing for all this. Can anyone help?
Darren
I forgot to add that the two databases will be identical and that the compact version is for offline usage.
Just to follow up on this. In the end I had to maintain two separate edmx files, one for sql server and one for compact. The main reason being that compact 3.5 does not support auto identities (as mentioned above by Zeeshan). This in turn led to two context classes. In the context class for sql server compact I had to put code to check for insertions, query the database for the latest id and increment it manually before saving.
Thankfully with the release of compact 4.0 this no longer applies as it supports auto id and you can indeed use just one edmx file.
Darren
You do need the edmx file as long as the schema is exactly the same. just change the connectionstring and everything would work seamlessly. Though i am not sure how u are saying that schema is same when compact edition does not support identity concept and full blown sql server does. So if you are using features specific to sql server that's not available in compact, then you would get runtime errors.