Hi

We are starting to use packages more and more in firebird. Is LLBLGENpro supporting this? I can't seem to get it to work. And if it isn't support, would you mind? It's a long weekend anyway

Kind regards

Alexander

Firebird packages are indeed not supported. From the looks of it they seem equivalent to oracle packages. As this is too close to release of v5.7, we can't implement this before that release so it'll have to wait. I'm sorry.

Otis wrote:

Firebird packages are indeed not supported. From the looks of it they seem equivalent to oracle packages. As this is too close to release of v5.7, we can't implement this before that release so it'll have to wait. I'm sorry.

understood, for now I can work around with "wrapper" methods. It is a bit silly, but it works for now. Packages are indeed the same as in oracle and are a nice feature to keep my code a bit cleaner in the db. It would be appreciated.

We've created a workitem, they'll be on our plate for the next version

Otis wrote:

We've created a workitem, they'll be on our plate for the next version

So guys... How is the thing going with the next plate? Finished previous one? I would love these functionalities to be mapped as well.

Now I am writing it nicely in packages and then making a dumb mapping procedure to use it. Totally not the plan and I would love to drop these steps.

I already migrated to 5.7.1

kind regards

Alexander

Next version will be 5.8, so that's not tomorrow. I understand it's cumbersome for you, but sadly we have other items with higher priorities to do as well.

I'm sorry.

We're in a bit of a catch-22. The Firebird ADO.NET provider's schemas for meta-data don't contain package information in the procedure parameters schema. This is problematic as in the situation where you have a proc Foo in a package and without a package, you'll get all parameters of both for 'Foo' and there's no package name in the set of meta-data.

We can query it ourselves, however the information we get back lacks type information, as the ADO.NET provider performs excessive type information processing before it returns the meta-data schema. The only 'solution' is to copy the code but as it's not a simple small function, this is a no-go. We could call into the Firebird ado.net provider but that requires is to take a hard-reference on the provider which is something we don't want to do either (as that has bitten us in the past).

So currently we can't determine the parameters for packaged procedures. We hope to find a solution for this, otherwise we sadly have to postpone this feature till the ado.net provider does contain package information.

Hi

I will ask Jiri Cincura to put it on his agenda. We are sponsor of the firebird.net provider. So he can take it into account.

thanks for the answer.

Alexander

Alexander wrote:

Hi

I will ask Jiri Cincura to put it on his agenda. We are sponsor of the firebird.net provider. So he can take it into account.

thanks for the answer.

Alexander

Great! We'll think of a solution in the mean time.

It is in the tracker, for now I just create stored procedures that call the internal packages. It is not perfect, but it works. It allows me to put the code in packages and use an llblgen wrapper.

http://tracker.firebirdsql.org/browse/DNET-983

Alright

We managed to get it working by using a bit of reflection on the assembly. So the driver will pick them up in v5.8 correctly (We query the meta-data ourselves now, and through reflection call the post process code in the ado.net provider to get the right types etc ). A little dirty but works fine. When the provider gets updated we'll replace it, if needed, with a call the the schema method

Hi

Firebird 7.5.0.0 solves the issue gracefully for you if you like. Jiri released it a few days ago and we're testing it now and it behaves correctly.

kind regards

Alexander

Thanks for the heads up We'll see if we keep the reflection bit (which works with older clients) or use the default route. Either way, it's implemented in the next version (5.8 )