| JDBCType handling during SP Execution [message #21073] |
Tue, 29 August 2006 02:44  |
Eclipse User |
|
|
|
Hi
The following static method is used to obtain the JDBC Type for a
datatype which is then used to register the IN/OUT parameters.
DataTypeHelper.getJDBCTypeForNamedType(String dataTypeName)
This static implementation doesnot allow DTP extensions to extend it for
DB specific datatype, VARCHAR2 for eg. in case of Oracle database. My
suggestion would be to extend SQLDataService (which currently has
String[] getDataTypes()) to handle this mapping.
Is there any other way of achieving this in this context ?
Regards
Anthos
|
|
|
| Re: [dtp-dev] JDBCType handling during SP Execution [message #21091 is a reply to message #21073] |
Tue, 29 August 2006 03:05  |
| Eclipse User |
|
|
|
work around for this would have been to override IDBItem
getDBItem(ProcIdentifier) in the IControlConnection implementation which
returns a overridden SQLObjectItem(=>IDBItem) instance, where the
ParameterDescriptor[] getParameterDescriptor() method is overridden to
handle this type mapping.
But SQLObjectItem is not exported by the
org.eclipse.datatools.sqltools.editor.core plugin and so results
following error when attempted to import into code.
Access restriction: The type SQLObjectItem is not accessible due to
restriction on required library
.....\eclipse\plugins\org.eclipse.datatools.sqltools.editor. core_0.9.0.200605101.jar
So a quick fix would be to export the class,
org.eclipse.datatools.sqltools.editor.core.internal.dbitem.S QLObjectItem,
in org.eclipse.datatools.sqltools.editor.core plugin.
Regards
Anthos
Anil Samuel wrote:
> Hi
>
> The following static method is used to obtain the JDBC Type for a
> datatype which is then used to register the IN/OUT parameters.
>
> DataTypeHelper.getJDBCTypeForNamedType(String dataTypeName)
>
> This static implementation doesnot allow DTP extensions to extend it
> for DB specific datatype, VARCHAR2 for eg. in case of Oracle database.
> My suggestion would be to extend SQLDataService (which currently has
> String[] getDataTypes()) to handle this mapping.
>
> Is there any other way of achieving this in this context ?
>
> Regards
> Anthos
> _______________________________________________
> dtp-dev mailing list
> dtp-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/dtp-dev
|
|
|
| Re: [dtp-dev] JDBCType handling during SP Execution [message #581971 is a reply to message #21073] |
Tue, 29 August 2006 03:05 |
| Eclipse User |
|
|
|
work around for this would have been to override IDBItem
getDBItem(ProcIdentifier) in the IControlConnection implementation which
returns a overridden SQLObjectItem(=>IDBItem) instance, where the
ParameterDescriptor[] getParameterDescriptor() method is overridden to
handle this type mapping.
But SQLObjectItem is not exported by the
org.eclipse.datatools.sqltools.editor.core plugin and so results
following error when attempted to import into code.
Access restriction: The type SQLObjectItem is not accessible due to
restriction on required library
.....\eclipse\plugins\org.eclipse.datatools.sqltools.editor. core_0.9.0.200605101.jar
So a quick fix would be to export the class,
org.eclipse.datatools.sqltools.editor.core.internal.dbitem.S QLObjectItem,
in org.eclipse.datatools.sqltools.editor.core plugin.
Regards
Anthos
Anil Samuel wrote:
> Hi
>
> The following static method is used to obtain the JDBC Type for a
> datatype which is then used to register the IN/OUT parameters.
>
> DataTypeHelper.getJDBCTypeForNamedType(String dataTypeName)
>
> This static implementation doesnot allow DTP extensions to extend it
> for DB specific datatype, VARCHAR2 for eg. in case of Oracle database.
> My suggestion would be to extend SQLDataService (which currently has
> String[] getDataTypes()) to handle this mapping.
>
> Is there any other way of achieving this in this context ?
>
> Regards
> Anthos
> _______________________________________________
> dtp-dev mailing list
> dtp-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/dtp-dev
|
|
|
Powered by
FUDForum. Page generated in 0.06318 seconds
Home