Dynamic grid business object connection?

Hi All,

Just looking into the best options for converting a V7 form to V9 and I'm not sure on what the best approach, if at all there is one... I suspect it's no longer "supported" which could end up being a big big headache!

I need to dynamically assign a connection for a grid source. In V7 we used a %SelectSQL statement in the grid's database name, username and password fields. This allowed users of the system to configure additional services within a database configuration table that could then be automatically used as a source within the Metastorm UI.

I've briefly investigated the new connection objects and BO's but I haven't seen how this can be supported without resorting to C# and initial investigation of the exposed methods and properties show that the classes produced for the business objects don't allow the setting of the connection string? hmmmmm

Has anybody out there tried to do this or does anyone know if it's possible (and if so - how) to set the connection of a business object at run time?

Thanks,

Paul.

Find more posts tagged with

BPM

Comments

Paul Lawrence

What do you mean by dynamic? do you mean between different environments (we traditionally read this from a config table) or at 'run-time' for specific folders. If it's at an envirnment level you can change the connection strings through the Administration tool. If it's run-time at a folder level then you might need to think of another way - maybe an external layer that you could call?

Paul_York

It's at the folder level Just working on a .NET workaround at the mo but it's feeling like a hack.

I also have a ticket open with the helpdesk to see if the functionality exists in a more "supported" way

Jerome_Pearce

The only way I can see to do this is by setting up all the required connections and seelcting the appropriate one at run time in a C# script.

You would never be able to use this for a grid or anywhere else that requires a Business Object to be set, but you could return it from a function with the same interface that the SelectSql() function does (we do that a few timws for option lists and the like).

Paul_York

But this is a limitation that didn't really exist in V7.

Providing the user had the necessary rights you could create the DSN at runtime (using .NET server side) and then re-use this DSN within the grids by using a %SelectSQl statement in the DSN, username and password fields select. This allowed you full blown dynamic sourcing of the data that you surfaced in the grid.

In V9, without explicitly knowing what sources will be used there is no way you can do this by setting them up first. We're updating a product that can be configured to use 1 or many databases with a known schema and surface certain information to the user. In this scenario it's up to the customer to configure what data sources they wish to register so we need to find a way around it and that way is currently looking a bit too like a hack for my taste!

Jerome_Pearce

I have to say we have similar problems because we use a great deal of dynamic SQL. In one system we have built we even used a dynamic database name as in .dbo.table in order to manage updates to one of seven databases on the fly.

All of that is broken in version 9, and we have had to come up with different ways to manage data. It was all possible (apart from the dynamic database name) with 'sleight of SQL' but it was painful.

I can see how your problem is less easy to solve.