Razzak: Awesome explanation.
I had a situation where the current behavior gave me unexpected results due to what you described. As always, gracious thanks to you and the Supreme eXtreme Dream Team. Kind regards. Mike Ramsour AK Steel Coshocton Works Quality Department Phone: 740-829-4340 Cell: 740-502-1659 From: "A. Razzak Memon" <[email protected]> To: [email protected] (RBASE-L Mailing List), Date: 06/26/2015 08:44 PM Subject: [RBASE-L] - Re: Timing of updated DB info Sent by: [email protected] At 11:38 AM 6/26/2015, Mike Ramsour wrote: >My basic question is at what point in time does the SYS_TABLES table and >the RX2 file reflect the insertion of data into a table when there is more >than one concurrent connection to a given database? > >Scenario: > >2 concurrent R:BASE sessions connected to the same database > >In session 1 a program inserts 10 rows into a table. A message is returned >stating that 10 rows were inserted into the target table. > >Switch to session 2 and do a list table on the target table from session 1. >The table structure is displayed but indicates 0 current rows. > >Browse SYS_TABLES for said table and SYS_NUM_ROWS also shows 0 rows. > >Switching to session 1 and browsing SYS_TABLES shows SYS_NUM_ROWS of 10. > >Is this due to transaction processing and AUTOCOMMIT being off? > >Thanks for any guidance and insights. Mike, Here is a "technical" explanation for your exact question & observation. Ready? Here you go ... In an R:BASE database, we normally think of table data being on the "2" file, index data being on the "3" file, and blob data being on the "4" file. The "1" file has data that applies to the entire database and has several sections, including one for overall data, one for settings, one for data about the tables, one for data about the columns, and one for data about the indexes. The table named SYS_TABLES actually gets its values from the information in file "1" about the tables. There are no rows in file "2" for this table. When one user/session of R:BASE adds new rows, obviously new data gets written to file "2", but additional data about that table such as the current row count gets updated in the table section of file "1". When the second user/session of R:BASE did the SELECT from SYS_TABLES, we did not force a re-read of the table data from file "1" so this user still sees the values from the last time the table section from file "1" was read, which was before user one added the new rows. If the second user/session had done a LIST command instead of a SELECT command they would have seen the new row count. The LIST command does a re-read of all the file "1" data before doings its display. The setting for AUTOCOMMIT has nothing to do with this behavior. Having explained that technically, the next update of R:BASE eXtreme 9.5 and R:BASE X (Version 10), will include the perfected SELECT from SYS_TABLES, that will force a re-read of the table section from file "1" to pick up any new row counts. As always, we are poised for perfection! Very Best R:egards, Razzak. www.rbase.com www.rbaseX.com www.facebook.com/rbase -- 32 years of continuous innovation! 17 Years of R:BASE Technologies, Inc. making R:BASE what it is today! --www.rbase.com www.rbaseX.com www.facebook.com/rbase -- 32 years of continuous innovation! 17 Years of R:BASE Technologies, Inc. making R:BASE what it is today! -- Confidentiality Notice This message is intended exclusively for the individual or entity to which it is addressed and may contain privileged, proprietary, or otherwise private information. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
