Relation/globals problem with modules

Hello,

I am having problems with the following setup:

  • Module A has Module B loaded
  • Module A has relations that depend on globals defined in Module B
  • Module A is loaded into a solution that also has Module B attached

While this was working fine almost all day, all of a sudden I get this kind of error:

The dataprovider globals.aktiviert or column ebene does not exist as defined in the relation spotlight_to_kategorien_ebene_1

The dataprovider globals.aktiviert resides in Module B and the column ebene does exist and can be seen from Module A.

I can fix this problem, go into the solution and work as I expect to. When I close Servoy, restart and reopen the solution, I get this error again.

Any ideas?

Thanks
Patrick

Patrick,

I don’t know if this will work or not (haven’t tried it - haven’t asked the dev team about it) - BUT:

What if you change the physical LOAD order? So, in the solution settings, make Module B the FIRST module and Module A the SECOND module? I’m not sure they load in the listed order - but give it a shot.

Further investigation shows that you cannot use a global of a module for relations in another module.

Could anyone comment on this? Otherwise I am forced to create those globals in every module and make sure they all have the value I expect…

Somehow I have the feeling that when you use globals with the same name in modules they contain the same value.
In other words they are one and the same. You only set the scope of a module-global by defining it in those modules/solution.

I haven’t tested this and it’s no more then a hunch.
But somehow it makes sense to me.

my view of this: modules or not, everything ends up in one solution as if it was defined in one solution. So wherever the global sits, it should be seen as long as all relevant modules are loaded.

I just would like to know if this is bug, a difficult issue, a feature, a missing feature or whatever. As long as I believe it is a bug I don’t feel like creating one and the same global in 10 modules.

Thanks
Patrick

If you don’t define a global in a module how can you ever use it inside that module ?
Regardless in what other solution/module it is used.

Please go back to the beginning of this post to see my setup. It is very simple:

I have a global that stores the user ID of the logged in user. I need user related information in many different modules. So I would have to create and fill (even worse) that global everywhere. Not having to do that I put that global (like some others like this) in a module I use for general methods and logic. This specific module (call it a utility module) is loaded in ALL my modules AND the solution itself.

If this is not supported, globals of sub-modules should not be offered when defining relations.

Everything works great until you restart Servoy.

I just like to know if this is a bug or if I have to change my logic (in 10 modules). So please, let us wait for an answer from the ones who know!

Hi Patrick,
Ijust did some testing using your configuration.
Things seemed to go wrong when using different named servers(server name of your db connection) in main solution , Module A, module B

When sticking to one named server over all modules/main solution I didn’t get any errors anymore.
Are you also using different named servers?
If so, do you have a test environment where you could verify if error disappears when reverting to 1 named server?

Meanwhile I will check with dev team.

I am only using one connection in these cases…

I have a module that shares a global with its parent solution and uses this global in a relation and do not have a problem. This is just parent solution and module and not module of module as you suggest. So, this seems like a bug to me.

patrick:

  • Module A has relations that depend on globals defined in Module B

Will not be longer possible to use globals from modules in relations, to get the same effect as before define the global in both(solution and modules) with same type

Ok, I am not so happy about you’re answer but I am happy that you did answer.

Thanks for clarification.