Rob, Hi!
> Here are a few tips: > > 1. Forget all you learned about 4D. Things like processes, process > variables, interprocess variables do not apply to RB. Thanks. I had realised this difference on the basis of the development I've already done. Yes, I'm trying to forget all about the 4D way of doing things, but it's not always so easy ;-) > 2. RB threads are not equal to 4D processes. A 4D process has its won > variable table (process variables). A thread has not. It has acces to > all the variables in your application. Thanks. I appreciate that 4D processes are not the same as RB threads. Up until now I was not creating my own RB threads. The reason for trying this way was that I (incorrectly as it turns out) assumed that as my whole application was running in the main RB thread then I perhaps I could solve my multiple transaction problem with multiple threads. Of course this was silly because I had only a single globally accessible database connection open through which all DB access takes place regardless of window/thread! > 3. There is no sense in opening a new window in its own thread. If > you use something like "Window1.Show" the thread would end right > after the window is opened (assuming there is no other code after > that line). Yes in 4D you would launch a new process to have multiple > windows to interact with. But that is not needed in RB. In RB you > will mostly use threads to do background processing. Yes, understood. Only tried this for the reason indicated above. > 4. In 4D each process had its own editing context (selection of > records, transactions etc.) There is no real equivalent when working > with SQL databases. Each recordset can be considered a selection. In > order to have multiple (individual) transactions you need multiple > connections. Yes, that's exactly how I solved the problem, i.e. open multiple database connections, one per window/transaction. > 5. Don't use transactions as an undo-mechanism as you would in 4D. > Instead store all the relevant data in memory and let the user edit > it. Once the user clicks the save button, you start a transaction > update the relevant records and commit (or rollback) the transaction. > This way you keep your transactions short and lock records only for a > short while. I have to disagree with you here - perhaps I will regret it! Consider this - I access a Customer record to which is related everything else such as Addresses, Contacts, Orders, Invoices, etc. Then 2 issues arise : * firstly, without the transaction you have to do more work to track which records are being added, modifed, deleted * secondly, I want to ensure that only a single user thinks they have WRITE access to the Customer record - this also automatically prevents another user from simultaneously making changes to both the Customer record and records in related table since they will get the record as READ ONLY access - to my mind the best way is via a transaction to secure the lock on the Customer record Of course, I'm open to alternate suggestions and strategies for record loading/locking for multi-user systems built with RB. Regards, Narinder. -- ___________________________________________ | Narinder Chandi, | ToolBox Systems Limited, | Surrey, England, UK. | http://www.toolbox.uk.com |___________________________________________ | Consultancy * Development * Support |___________________________________________ _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
