OpenEuphoria

RE: Berkeley DB with Euphoria

• Posted by rudy toews <rltoews at ilos.net> Sep 30, 2002
• 420 views

Andy Serpa wrote:
> I cached the key_pointers in my version in a very simple way.  Speeded 
> it up enormously when flipping between tables.  When it selects a table, 
> 
> if there is already a "current table" it saves the pointers for that 
> table in a global sequence, then it checks to see if it already has the 
> key pointers for the new table in memory, and if so grabs them, or else 
> loads them in as normal.
> 
> On a db_close or db_open it clears them out, so it only works if you're 
> using one db at a time (with an exclusive lock).  I only had to add 
> maybe 10 lines.
> 
> To keep multiple databases open without selecting between them all the 
> time (a fixed, known number of them), I believe (I haven't tried it) the 
> 
> "namespace trick" would work, even if it is an ugly solution:
> 
> include database.e as dbA
> include database.e as dbB
> 
> Now using namespaces with all the db functions you could keep them 
> separate, right?
> 
> 
> Robert Craig wrote:
At the very outset, in designing EDS, I had a choice
> > of:
> >     1. have the user specify the database & table 
> >         on each operation, 
> > or:
> >     2. have a "context" where the database and
> >         table were established beforehand, and all database
> >        operations would have shorter parameter lists.
> > 
> > I went with #2. I don't regret it, but there are situations
> > where it is inconvenient. 
> > 
> > When you select a table, EDS reads in 4 bytes per record
> > in that table. This is inefficient when you have a lot of records
> > (over 1000 say) and you are trying to rapidly flip back and forth 
> > between tables. Obviously some buffering would help,
> > i.e. keep the record pointers in memory. Maybe I'll do something
> > about this. Note that it's dangerous to modify part of the data base
> > structure in memory only, in case your program crashes 
> > and the database on disk is left in an inconsistent (corrupted) state.
> > Simply keeping a copy of the record pointers in memory 
> > should be safe as long as other processes are locked out from
> > making changes. There's also the issue of how much memory
> > this might require. If you have lots of tables with lots of records
> > you might run out of memory. 
> > 
> > If you look at db_compress() you'll see that it copies records,
> > between tables, 20 at a time. That's another approach 
> > to the problem.

Thankyou Rob and Andy

hmm, i didn't really think of making a copy of the database functions 
and renaming them so they don't get mixed. i will give it a shot when i 
have progressed more on my windows programming level. almost understand 
how statements start to fit together to get what i want done. (danger 
level).

recently i have seen the colon used in functions that Phil Russel is 
working on in creating EuGrid. i forgot what the notation below means, i 
have seen it before but i don't remember (win32lib or somedatabase 
routines).

newkey = noah:saveanimal(dataset[i])
does it let noah refer to the current open window or .e file?
allowing multiple uses of the same function name?

thanks again
rudy

the use of the colon 


lotterywars