1. RE: data base access
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
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
--- 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
