Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 12 of 12 total
Thread How many databases can a single session support?
Sun, Feb 28 2021 9:07 PMPermanent Link

Shane Sturgeon

Thank you both - I'm still pondering, but think that the smartest course of action at this point is probably just doing a single DB and telling the user if they don't like the size of the backup, delete some businesses.
The app is modelling financial transactions (forecasting and budgeting) rather than tracking actual real live business data, so in a lot of cases, the shelf life of a model will be no more than 12 months.

Roy Lambert wrote:
>>I'm glad you brought up EDBManager. If you hunt assiduously through the suggestions newsgroup you'll find a request for an option to change the colour of the UI between sessions. I asked for this because I (and I suspect others but cannot prove it) have forgotten which session / database I was in. Its easily done when you have the same structure and you're using SQL. <<

I know exactly what you are referring to - I've had this problem myself last week, where I wasn't sure which database ended up with the new table I was adding - only thing I knew was it wasn't the one I thought was going to get it.


And Raul's comment (>>I would suggest to also consider shared config/catalog issues - things like same set of users, stores, backups etc for all databases.>>) has now got me thinking about my plan (or more specifically lack on one) on this front. I was planning to just use the default admin/pass etc. in the application - it's not multiuser (think of it as the user will use my app because it's quicker, easier, more structured etc. than using a spreadsheet).

Even in the case of a single user on a single machine, should I be creating a limited user for the Delphi app to use when accessing the tables etc?

>> Not mentioned yet - are there common files (eg accounting codes) and what were you thinking about for those?>>
This is definitely a requirement in some cases, and for those the app was going to allow multiple models in the same DB (as per the original concept), and the chart would be shared. That was actually what got me thinking more about this, specifically the way to link journals to specific entities when the chart of accounts was shared - seemed the only way was to include the entity key with the journal and some quick calculations started getting me worried about the size of the database, especially when there would also be many models where the storing of the entity key with every journal record would not serve any purpose (stand alone model). I've thought of a way to reduce that burden by a factor of 30 odd, so current plan is to proceed with a single DB and see what the situation is like in practice.

Thanks for your help. And +1 for your color coding idea Roy Smile





Roy Lambert
Mon, Mar 1 2021 3:19 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Shane

>Even in the case of a single user on a single machine, should I be creating a limited user for the Delphi app to use when accessing the tables etc?

If not then a supplementary password for the "oh shit I shouldn't have pressed that" functions is a good ides.

>>> Not mentioned yet - are there common files (eg accounting codes) and what were you thinking about for those?>>
>This is definitely a requirement in some cases, and for those the app was going to allow multiple models in the same DB (as per the original concept), and the chart would be shared. That was actually what got me thinking more about this, specifically the way to link journals to specific entities when the chart of accounts was shared - seemed the only way was to include the entity key with the journal and some quick calculations started getting me worried about the size of the database, especially when there would also be many models where the storing of the entity key with every journal record would not serve any purpose (stand alone model). I've thought of a way to reduce that burden by a factor of 30 odd, so current plan is to proceed with a single DB and see what the situation is like in practice.

Remember the chart of accounts is basically a tree so if you have the company as the root and make the table keyed on company:code:transactionID you should have no problems.

>
>Thanks for your help. And +1 for your color coding idea Roy Smile

You could even stuff the company name/logo in the top right of every form.

Roy
« Previous PagePage 2 of 2
Jump to Page:  1 2
Image