1. RE: data base access
- Posted by Jonas Temple <jktemple at yhti.net> Aug 03, 2001
- 422 views
George Walters wrote: George, Being that I have spent a lot of time with database.e developing similar apps to what you're working on I wanted to interject my thoughts: If you are developing MULTI-user business apps (they are usually mult-user) with straight database.e then you are going to run into trouble. The docs pretty much spell out that database.e is not intended for multi-user access. Files opened with database.e don't share well and using record numbers to access data will eventually crash your progrram if you have more than one user accessing the same file. I suggest you check out me EDS/Net package on the contributions page. This allows multi-user access of database.e functions across an IP network. It's by no means perfect but it seems to be pretty stable. Your wish list of additional functions: > ic_record = db_read( db_opened_table[x], item_key) -- with one read and > items 1-4 be taken care of internally. > ic_record = db_readnext(db_opened_table[x]) -- to provide the next > ic_record = db_readprev(db_opened_table[x]) -- to provide the > previous > db_add_record(db_opened_table[x], ic_record) -- adding to file > db_update_record(db_opened_table[x], somePartKey, somePartRecord) > db_delete_record(db_opened_table[x], somePartKey) are there as well! I am committed to continue improving EDS/Net. I am currently working on speeding up record retrieval for large number of records. The administration interface is also going to get a re-write. Try it and see if it works for you. I would also welcome any suggestions/feedback. Good luck. Jonas
2. RE: data base access
- Posted by Jonas Temple <jktemple at yhti.net> Aug 03, 2001
- 414 views
George Walters wrote: > Thanks Jonas, you're right that eventually the multi-user issue has to > be > solved. I have looked at your eds/net, and you do have some more direct > access to records but the 'current table' issue would still be a problem > in > a program reading from so many different data bases. > > ..george George, Although I think your concern is valid I can't really say that having to do db_select and db_select_table would be a measurable problem from a performance/coding perspective. Consider this...if Rob changed database.e to support multiple open databases as you suggested then you would have to code to support the different file handles. Coding for the current method only requires you to supply a database name/table, something you would have to do anyway (since db_open requires a table name). One thought would be to pass the database/table to each record access function in database.e. For example: record_data = db_record("mydb", "mytable", record_number) Then database.e could handle the database/table switching internally. Maybe this is what you had in mind? Rob, hoping that you read this, I would like to again request a thought on indexes withing database.e. What do you think? Jonas
3. RE: data base access
- Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> Aug 03, 2001
- 433 views
--- Jonas Temple <jktemple at yhti.net> wrote: > George Walters wrote: > One thought would be to pass the database/table to each record access > function in database.e. For example: > > record_data = db_record("mydb", "mytable", record_number) This is the approach I've taken with EuSQL, where an empty string indicates to use the current db/table. (It's possible to do everything through straight SQL commands or using the API functions to manipulate a db). > Rob, hoping that you read this, I would like to again request a thought > on indexes withing database.e. What do you think? I'm in the process of getting indexes to work with EuSQL. I've picked it up again, and have squashed a few bugs, and improved some other things, like how it handles 'where' clauses. My approach to indexes is to have a 'system' table, 'INDEXDEF', in which each index is stored. Queries can then use the index to quickly do (large) joins on the data. I'm actually using Jiri's a-list code to handle the indexes, which are stored with the indexed value as the list-key, and the list-data being a sorted list of the record keys which correspond to the value. Each record in INDEXDEF is an index on a field. ===== Matt Lewis http://www14.brinkster.com/matthewlewis