Hi Folks:
Trolling back into Servoy water here as the product gets better with each release.
I’ve been out of the loop for awhile, but Yvo tells me that the current version of Servoy does support individual user Logins to the SQL database.
Can someone point me to where in the documentation this is described and how it’s implemented? This is important for our intended security model.
Thank you!
Lee
No one has any clue on this?
Is it just a misunderstanding from the Sales dept?
Well, you could use individual logins by setting up a database server with each login you want to use, then during the login phase of your solution, you could use the switchServer function in the databaseManager node.
Jason
That’s what I was thinking too but switchServer only works with already defined Servoy connections and you are not allowed to create several connections that connect to the same database (for obvious data-broadcast reasons). Not sure if the username differences (for those connections) make it a unique connection then, never tried it.
They made it sound like this was a standard feature and being used by one of their larger accounts. So, something that involves a “trick” or a lot of extra setup does not sound right. I’ll have to press Yvo some more.
Regards,
Lee
Different users require different logins. That means you have to have different connections and it is possible to create those “duplicates” with different user names (almost sure ). Downside is that you have more connections than are actually necessary on the database side as well. I wonder if large accounts really prefer to (believe to) be more secure when the downside is that they have to afford unnecessary connections. So maybe it is easier to convince them that a Servoy solution can also be made secure? But if it is really required (because maybe access rights should be maintained at one place) then it should be possible with switchServer.
Keep in mind that if you use switchServer you will have to setup all the autoenter options, table events, converters, etc for any defined server. All of them need to be in sync and that could be a real PITA if you have many db connections defined.
ngervasi:
Keep in mind that if you use switchServer you will have to setup all the autoenter options, table events, converters, etc for any defined server. All of them need to be in sync and that could be a real PITA if you have many db connections defined.
Servoy will keep these in sync for you.
Table events and converters are defined on the main server and will be applied transparently to the switched-to server.
For auto-enter options, there was a bug that the main server definition was not used on the switched-to server, this is fixed in release 4.1.3 which we expect to release this week.
Rob
rgansevles:
For auto-enter options, there was a bug that the main server definition was not used on the switched-to server, this is fixed in release 4.1.3 which we expect to release this week.Rob
You can’t imagine how grateful I am…
Tnx Rob!
ow really??
Also, new added columns?
Harjo,
I am talking about the solution model (column info, aggregates, auto-enter options, etc), not about the data model.
Servoy <= 4.1 expects the data models to be the same.
In Servoy 4.2 we introduce a new feature where multiple server data models are updated with 1 import.
Rob
oke great! Thanks…
rgansevles:
Harjo,I am talking about the solution model (column info, aggregates, auto-enter options, etc), not about the data model.
Servoy <= 4.1 expects the data models to be the same.In Servoy 4.2 we introduce a new feature where multiple server data models are updated with 1 import.
Rob
Sorry to hi-Jack but could you expand on this please Rob - do you mean if I switch server the solution will update each of the server’s I connect to with data structure changes?
If not what is the best method of updating the multiple servers that I might switch to?
Ian,
In 4.2 we have a new attribute in server definition that links one server to another (‘is a clone of’).
When an import in the main server has data structure changes, these will be applied in the ‘clone’ servers as well.
This setting is only used while importing solutions.
Rob
ngervasi:
rgansevles:
For auto-enter options, there was a bug that the main server definition was not used on the switched-to server, this is fixed in release 4.1.3 which we expect to release this week.Rob
You can’t imagine how grateful I am…
Me too
Thanks, Rob.
bubba:
They made it sound like this was a standard feature and being used by one of their larger accounts. So, something that involves a “trick” or a lot of extra setup does not sound right. I’ll have to press Yvo some more.Regards,
Lee
There is no trick it is a standard feature and not hard to setup at all.Having said that: yes using a 2-tier approach (which you are essentially doing) in an n-tier world will always be more work than just working with the n-tier rules in the n-tier world! .
Ofcourse you loose one of our coolest features: databroadcasting, think about an n-tier architecture and you will understand how much work this would be to automagically understand to how your underlying oracle connection is connecting to which physical table: next to impossible, there’s a million ways of doing it (trust me I’m an ex oracle db, I know what I’m talking about)
As some extra info: for databroadcasting to work properly there can only be one database server connection defined in Servoy that points to a physical database (schema/catalog).
In other words, a (set of ) tables should only be accessible through one Database Server connection.
If you have multiple Database Server connections defined that can access the same table, databroadcast will not work between the different connections. so, if you have three clients, all accessing table customers, where client 1 and 2 do this over database server connection S1 and client 3 does it over database server connection S2, if client 3 does an insert/delete/update on the table, clients 1 and 2 won’t be notified. If client 1 does the insert/update/delete, client 2 will be notified (as he is accessing the data through the same database server connection), but client 3 will not be notified.
Hope this makes it clearer,
Paul
Jan and Paul:
Thanks for the additional info. The loss of broadcasting is a big drawback, but not insurmountable.
In a single connection model, does the “Table Filtering” feature of Servoy operate at the SQL Database level on an individual user basis, or is this filtering being done within the “Servoy” code, cache.
Thanks,
Lee
rgansevles:
Ian,In 4.2 we have a new attribute in server definition that links one server to another (‘is a clone of’).
When an import in the main server has data structure changes, these will be applied in the ‘clone’ servers as well.This setting is only used while importing solutions.
Rob
VERY Cool Rob - I’ll investigate! Thanks
In a single connection model, does the “Table Filtering” feature of Servoy operate at the SQL Database level on an individual user basis, or is this filtering being done within the “Servoy” code, cache.
Tablefiltering is always session specific, so bound to the user
Paul