Re^2: Simultaneous access to the tk script

Hi,

and many thanks for your reply. My application has two tables. In a nutshell: the first table is inventory management and the second table is a manual log. The tables are linked over product_id. The users can write in the second table only (in essence, a current comment from the user view). This means, they will never update the same record, they just write in the same table. The likelihood of writing at the same time up to millisecond is probably low. Would you say it is still useful to set $dbh->sqlite_busy_timeout( $ms ) here?

My concern was the packed Tk front-end as well, since many / several users would start the same programm over the link. Well, probably 20-30 is not too many. I will try to find out where the %temp% is located as Anonymous Monk proposed here.

The clients' update would be less of a concern in my specific case. The users make their notes to the different products. In the moment that they would like to see the actual chain of log records to the certain product they load the id manually.

Comment on Re^2: Simultaneous access to the tk script Select or Download Code

Replies are listed 'Best First'.
Re^3: Simultaneous access to the tk script by Marshall (Canon) on Jun 04, 2018 at 18:52 UTC
I don't see any "show stoppers" with your application. 20-30 instances of a packed Perl program with Tk sounds reasonable. Of course the program will start faster if you have Perl and the modules that it needs installed because this eliminates the "unpack the .exe" step. However in my experience the users will be tolerant of a couple of seconds startup time, above 3 secs and you will get bitching (or at least I do). The last time I did any SQLite benchmarking, I was using an old XP laptop as my development machine. I could get maybe a dozen transactions per second. And about 50K inserts per second (as single transaction). Your server machine is undoubtedly faster than that. In your case to initialize the inventory table, run all of the inserts as a single transaction. A million row commit is just fine with SQLite. The write commit process has a lot of bookkeeping to do, but there isn't much difference between a single row commit and a 10K row commit. Each one of your writes to table 2 in operational mode will be a transaction. So max write rate is probably less than a couple of dozen per second, but even if you just get 10 per second, that is probably fine. Sounds like each user will be doing a fair amount of thinking before making a manual comment. Sounds like you have a fine SQLite application.	[reply]
Re^4: Simultaneous access to the tk script by Anonymous Monk on Jun 06, 2018 at 17:54 UTC
Thank you very much!	[reply]
Re^5: Simultaneous access to the tk script by Marshall (Canon) on Jun 06, 2018 at 20:20 UTC
I wish you well! I would encourage you to sign-up for a Monk Account so that follow-up questions, etc are easier to connect with previous replies.	[reply]