Servoy Forum

Posted: **Wed Oct 03, 2007 1:34 pm**

For some reason the PHP Debugger is throwing a fit with this message. I'd appreciate if you guys would take a look at the attached text though.

TIA

Cheers

Posted: **Wed Oct 03, 2007 1:58 pm**

I think it is the hanging comma's ('n).

Have you created the text within the forum editor?

Posted: **Wed Oct 03, 2007 2:56 pm**

This forum doesn't handle high-bit characters and your message is full of them (e-umlaut, i-accent, ~ over n (forgot the proper name for it) etc.).
So that is the reason why you couldn't post it.

Hope this clears things up.

Posted: **Wed Oct 03, 2007 3:10 pm**

Here is a cleaned up version:

Kahuna wrote:Structuring a Solution for Multi-Clients / Multi-Db's
Hi Folks - this is possibly in the wrong forum - but here goes - feel free to move me around!
------------------------------------------------------------------------------
Covering some old ground here , but I need to get this straight in my head before we detail the MSA97 app port to Servoy.

Currently the app is a Front / Backend set-up. I have several Clients each of whom has several databases running , i.e.:

Client1
--------?DBa
----------------?CostsTablei
--------?DBb
----------------?CostsTablei
--------?DBc
----------------?CostsTablei

Client2
--------?DBa
----------------?CostsTablei
--------?DBb
----------------?CostsTablei
--------?DBc
----------------?CostsTablei

Each ClientUser has a frontend on his PC (or TS Desktop) connecting to a ClientServer where (all of) the Backend(s) reside.

Each of the CostsTable's can have different data dependant on the Client requirements for that DB, though the field names and ID's are the same. The structure of each DB is identical and simply named differently.

Currently upgrading is a nightmare , each copy of the frontend needs to be updated, links inside the frontend have to be modified after installation (so the specific user gets to the right database a,b or c , some need access to all etc.) and of course the backend needs to be downloaded to my dev box , modified and re-uploaded to the Client server.

In future, some Clients will use the Smart Client over the web to our servers, and some will have the system installed on their own servers and use the Lan / Wan. I'm hoping to use the WebClient too eventually.

Thinking about how we could do it differently, and ease the upgrade path lead me to these two main question:

1. Using Our / Client Servers:
With multiple Clients using the same solution, can I drive Client1 to DBa and Client2 to DBb etc? They can't (with the current structure) use the same CostsTables (and other tables) so diferent DB's are essential.

FYI: It would be possible to have all Client DB's in one huge structure and 'Filter' only the data for a given (current) DB's data. That would require a fairly dramatic restructuring however and entail a pretty big revision of the current Client data tables , I'd like to avoid that. With our current Clients having 20 , 30,000 records in the main tables and the same in cost files, aggregating several of them (Clients) in one DB would almost certainly cause performance challenges.

2. Can the above be done and still retain a common solution for both Our / Client server installations, or do I need a separate Solution for each Client / DB.

I'd really appreciate your feedback on these structures , before we get too far down the line (we'll need to get quite a way forward to test these for ourselves).

Anyone had similar challenges

Cheers

Posted: **Wed Oct 03, 2007 3:23 pm**

Kahuna wrote:1. Using Our / Client Servers:
With multiple Clients using the same solution, can I drive Client1 to DBa and Client2 to DBb etc? They can't (with the current structure) use the same CostsTables (and other tables) so diferent DB's are essential.

Yes you can do that with databaseManager.switchServer(). So you switch DB server connection after a user logs in.

Kahuna wrote:FYI: It would be possible to have all Client DB's in one huge structure and 'Filter' only the data for a given (current) DB's data. That would require a fairly dramatic restructuring however and entail a pretty big revision of the current Client data tables , I'd like to avoid that. With our current Clients having 20 , 30,000 records in the main tables and the same in cost files, aggregating several of them (Clients) in one DB would almost certainly cause performance challenges.

30,000 records is nothing for a SQL database. If you are talking many million rows then you might reconsider.
Just make sure your database is optimized (indices (or not), datamodel) and your database server is optimized.

So in short, yes you can use 1 single code base for all clients and when needed you could use 1 single database and use tablefilters.

Hope this helps.

Posted: **Wed Oct 03, 2007 6:20 pm**

Thanks to you both - Robert and Marcel.

My message did'nt have any umlats in there to start with! But did have hanging quotes as you point out.

Thanks for the feedback on the server setup.

I'd still like to have seperate databases (dataservers?) and switch between them.

Any guidance on how that might be facilitated based on the User / Group login?

Broad-brush please guys - I'm sure most of this will be revealed as we progress through the development - and I dont want to bog the forum down with NooB questions, but point in the right direction would always be welcome.

Posted: **Wed Oct 03, 2007 9:53 pm**

Kahuna wrote:Thanks to you both - Robert and Marcel.

My message did'nt have any umlats in there to start with! But did have hanging quotes as you point out.

Might have been a text encoding difference that I saw them. I opened it up on a Mac.

Kahuna wrote:Thanks for the feedback on the server setup.

I'd still like to have seperate databases (dataservers?) and switch between them.

Any guidance on how that might be facilitated based on the User / Group login?

Broad-brush please guys - I'm sure most of this will be revealed as we progress through the development - and I dont want to bog the forum down with NooB questions, but point in the right direction would always be welcome.

Well you simply have to code the logic yourself. It's not a build in feature in the Servoy users/groups but just a function you can call in a method.

Hope this helps.

Posted: **Wed Oct 03, 2007 10:08 pm**

Cheers Robert - I'll play with it.

I've had a 4 hour developer meeting today and its amasing what has 'come out of the woodwork' already!

Its gona be fun...