Hi There

I'm running LLBLGEn v2.6 final using the oracle 10g/11g driver(ODP.NET 10.2.x) for a C# .NET 2.0 application.

Our DBA has created several stored procedures which have oracle type Number(4,2) but which are mapping to system.Decimal (.NET type ) with a scale of 0 instead of 2 which means that valuesa are being truncated when passed to the stored procedures.

Is there a way to map this oracle type to a system.decimal with a scale of 2 using type converters or custom templates or any other means I am unaware of ?

Thanks Col

Which LLBLGen Pro runtime library version are you using?

There was a fix in the Oracle DQE in late August, please make sure you are using the latest release of LLBLGen Pro v.2.6

Hi

I downloaded the latest version of LLbLgern V2.6 but the issues is still occurring also I am having difficulty in refreshing the oracle catalog Do I have to place the runtime libraries in a specific folder?

Thanks Colm

I am having difficulty in refreshing the oracle catalog

What exactly are you facing?

Do I have to place the runtime libraries in a specific folder?

The new RTLs should be placed inside the RuntimeLibraries folder in the llblgen installation folder. Would be better if you download the full installation package and just install it and it will manage to put everything in place.

I open the project then click project -- refresh all catalogs then connect to the relevant database and click retrieve schema after which I get the following error message

" Item has already been added. Key in dictionary: 'P_OBJECT_NAME' Key being added: 'P_OBJECT_NAME'

-----[Core exception]-------------------- at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add) at System.Collections.Hashtable.Add(Object key, Object value) at SD.LLBLGen.Pro.ApplicationCore.CatalogRefresher.MigrateSPCallParameters(SPCallDefinition spCallToMigrate) at SD.LLBLGen.Pro.ApplicationCore.CatalogRefresher.MigrateActionSPCall(SPCallDefinition spCallToMigrate, ArrayList& procsToRemove) at SD.LLBLGen.Pro.ApplicationCore.CatalogRefresher.MigrateActionSPCalls() at SD.LLBLGen.Pro.ApplicationCore.CatalogRefresher.MigrateProjectToNewCatalog(Boolean isUnattended, SelectTargetsForOrphanedElementsCallBack targetSelectCallBack) at SD.LLBLGen.Pro.Gui.Forms.MainWindow.RefreshCatalogs(Boolean unattended, Hashtable catalogsToRefresh) at SD.LLBLGen.Pro.Gui.Forms.MainWindow.RefreshAllCatalogs(Boolean unattended) at SD.LLBLGen.Pro.Gui.Forms.MainWindow._menuItemProjectRefreshCatalogs_Click(Object sender, EventArgs e) at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ToolStrip.WndProc(Message& m) at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam "

Yes I have downloaded the full v2.6 version and installed it so the runtime libraries should be in the correct paths.

Thanks Colm

Oracle stores stored proc parameters as NUMBER(), without precision/scale, so they always will turn up as Decimal(38,0), simply because that meta-data isn't available.

Your error in the driver is caused by overloaded procs which aren't supported. Still the crash shouldn't happen, the proc should have been ignored.

To track down that exception, could you please check if your schema has overloaded procs? (proc with same name/package and different #of parameters) ?