Hi,

I want to do the same as Ertan. So, I'm interessed by this topic.
If I understand, :

For the moment, if I want to execute my application with SQL database I must to build the schema against the SQL table and if I want to execute my application with Oracle database I must to build the schema against the Oracle table.

So, I need to have 2 BO for the same table with parameters of each database.

I hope there will be a solution soon.

Regards,
David

Well, let's get to the crux of this topic as this is not going to be a quick post and falls more on the side of consultation.  This can become a very deep and complex topic which is not the intent of the forum.  But here is the bottom line when you are trying to do something like this (which is possible but requires some good foundation laying).

You should always create a base BO which all of your BOs within your application inherit from.  So let's just say BaseBO.  Within this base BO, I am going to overwrite the FillDataTable method.  I may need to override several others as well before all is said and done in order to take the automatic conversion into account.

When writing your application, you will always want to create your queries, etc. towards a specific database (i.e. SQL Server).  Now let's assume that you have the need to implement Oracle.  I will create a shared property within my application to which the BaseBO looks.  If it is set to Oracle, then anytime that the FillDataTable is called, the BaseBO will automatically convert an SqlDbCommand into an OracleDbCommand.  This is the approach that we have used within our medical software and it has worked just fine.

Next, you may need to "scrub" all values through an Accessing event or by overriding or shadowing the CurrentRow property or something along those lines if there are type conversion issues.  But again, this will be done within the BaseBO so that you only have to place this logic in a single location.

I'm waiting for Strataframe developers to give me guidance and roadmap.

Ertan,

I thought that we had.  I am unsure of what you are wanting from us.  We have given you all of the advice that we had intended to give on this particular topic.  Creating the solution for you is far more in depth and complex.  Now if you get stuck within a very specific section and want to discuss that section or detailed item then we can, but past that I feel as though we have done all that has been required by trying to give you that "roadmap" without actually coding the logic for you.

Sorry, I've not seen your response because I've forgotten to look at the next page. So, I've written a post about waiting guidance and roadmap.

I've understood your advice for external queries. But What about queries generated by strataframe. ? I've found a point that I've written above as a post. As explained in that post, INSERT,UPDATE and Delete queries can not be executed because there is a need for type conversion from SQL TO ORACLE. This is the critical point. The case have to be solved by Strataframe developers.

I've solved  for the external queries. 

Actually this is not something that needs to be changed by SF developers, but rather something that you should take into account in your application.  We have no intention of making the SqlDataSourceItem try and figure out of a data type should be converted into an Oracle item..this would break a lot of peoples applications and is not something that we are going to do.

Now, since you have this need, you can do this quite easily yourself.  You already have your application setup to determine if you are running SQL or Oracle and since you have this need, this would be my suggestion.  Create your own data sources.  You have the SF source code, so you can copy the code from the SqlDataSOurceItem and create your own...or just inherit from the SqlDataSOurceItem and override the CreateDbCommand (probably the better route) and then take this into account yourself.  You can copy the code from the SqlDataSourceItem or the OracleDataSourceItem so that you can see exactly what the CreateDbCommand is doing and then adjust this to meet your needs.  This is going to be the route that you will need to take...and it doesn't require anything whatsoever to be done within the framework itslef but rather is specific to your application.