Problem with tableadapters, directdbMethods and parametertyp
Posted: Wed 03 Mar 2010 12:21
Hi
We are currently in trial for dotConnect for Oracle, and we consider buying licences and move existing projects to new driver, from system.data.oracleclient. The main reason is performance, that is better, from our tests.
We are using strongtyped datasets and table adapters, and only in 1.5 days of testing your product, we already found problems that are not allowing us to continue with the new oracle connector.
I will list here two that are the most important, in order to know if there is maybe some config that is needed, or some workaround.
1. The numeric oracle fields (from db) are mapped in any new datatable we create with your adapter with int32, decimal, double by the case. The problem is that, for any new fillby method we add to tableadapter, all numeric parameters are created as decimal. We have some issues with that:
a. migrating existing datasets is dificult, because in entire BLL code, we used all strongtyped fields as decimals (as they were created by microsoft oracle client), and now we need to refactor entire code to match the new column types.
b. manually changing the column types to decimal is out of the question, since further management of the dataset schema (on schema evolution) is impossible. (changing the select string, to add another column for example, will duplicate all columns in model, because the existing one don't match the database type, but also, the dataset generator is not deleting them) - from this point, the dataset class is borken, and cannot be used any longer, withour redesigning from scratch.
c. A fillbycolumn method, will need decimal parameters all the time for any numeric field. But this will require additional work to convert parameters. Let's say that we have a table with locationId primary key numeric(4). The table generated in the datamodel, will have locationId int32 in this case. If we add a querry in the dataset designer for fillbylocationId, this method will require decimal, and we will not be able to use something like fillbyloactionId(model.locationRow.locationId) for a child table, and we need to manually make a conversion to decimal, and this is out of the question.
2. DirectDbAccessMethods (insert, update, delete) for table adapters are generated only in the first time, when you are initialy dragging the table from the server explorer, and only with "Optimistic concurency" on. If you put "optimistic concurency" off, the methods are not generated anylonger. And anyway, after this change, even if you put optimistic back, the methods for directdbaccess are not beeing generated anylonger. Optimistic concurency is also out of the question because the system is highly dynamic.
These issues are realy important to fix, and without some solution, we cannot proceed with dotConnect, even if it has best performance.
Thank you for support.
Florin
We are currently in trial for dotConnect for Oracle, and we consider buying licences and move existing projects to new driver, from system.data.oracleclient. The main reason is performance, that is better, from our tests.
We are using strongtyped datasets and table adapters, and only in 1.5 days of testing your product, we already found problems that are not allowing us to continue with the new oracle connector.
I will list here two that are the most important, in order to know if there is maybe some config that is needed, or some workaround.
1. The numeric oracle fields (from db) are mapped in any new datatable we create with your adapter with int32, decimal, double by the case. The problem is that, for any new fillby method we add to tableadapter, all numeric parameters are created as decimal. We have some issues with that:
a. migrating existing datasets is dificult, because in entire BLL code, we used all strongtyped fields as decimals (as they were created by microsoft oracle client), and now we need to refactor entire code to match the new column types.
b. manually changing the column types to decimal is out of the question, since further management of the dataset schema (on schema evolution) is impossible. (changing the select string, to add another column for example, will duplicate all columns in model, because the existing one don't match the database type, but also, the dataset generator is not deleting them) - from this point, the dataset class is borken, and cannot be used any longer, withour redesigning from scratch.
c. A fillbycolumn method, will need decimal parameters all the time for any numeric field. But this will require additional work to convert parameters. Let's say that we have a table with locationId primary key numeric(4). The table generated in the datamodel, will have locationId int32 in this case. If we add a querry in the dataset designer for fillbylocationId, this method will require decimal, and we will not be able to use something like fillbyloactionId(model.locationRow.locationId) for a child table, and we need to manually make a conversion to decimal, and this is out of the question.
2. DirectDbAccessMethods (insert, update, delete) for table adapters are generated only in the first time, when you are initialy dragging the table from the server explorer, and only with "Optimistic concurency" on. If you put "optimistic concurency" off, the methods are not generated anylonger. And anyway, after this change, even if you put optimistic back, the methods for directdbaccess are not beeing generated anylonger. Optimistic concurency is also out of the question because the system is highly dynamic.
These issues are realy important to fix, and without some solution, we cannot proceed with dotConnect, even if it has best performance.
Thank you for support.
Florin