1. RE: EDS cry out!!!! Rob, Andy Sepa, anyone]
sorry rob, but i'm not getting you.
how would i copy these keys? coz the only way i know would be using
db_insert(). what do you mean they are unique. db_find_key returns an
integer eg1 or 3. isn't it possible it could interfere with other keys
in other tables.
sorry, rob. i just don't know how the database.e library works? I know
how to use it and it is the key component of my application. please be a
bit less technical.
Robert Craig wrote:
> Jordah writes:
> > what did you mean? Do you mean that instead of copying the
> > data in the record i could simply copy the record key to
> > another table and it would work fine.
>
> No, I didn't mean to suggest that EDS would do anything
> for you automatically or magically.
> I just meant that since keys are unique,
> you could leave the large chunk of data in one place, and
> just copy the (small) key value around to various tables.
> You could then retrieve the data any time you want by
> the usual method: select the table, look up the record by key
> (it's fast because it uses binary search), then access
> the (large) data for that record.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
2. RE: EDS cry out!!!! Rob, Andy Sepa, anyone]
Jordah,
I assume what you really want to do here is move key and data from one
table to another.
Here's a suggestion:
I would create two sequences, maybe keys and data. I would also
determine the largest amount of data you could store temporarily before
you run out of memory. Then I would move a block (say 100 records) at a
time from the source table to your keys and data sequences, switch to
the target table and move the keys and data sequences to the target
table. Then clear the keys and data sequences for the next block. You
would, of course, need to retain the last record number you got from the
source table so when you switched back to the source table you could
pick up where you left off. Sorry, I don't have code examples, this is
really just a theory.
I think what you're frustrated over is the fact that you can only refer
to one table in one database at a time. However, the intent of EDS was
to be simple to use. That it is, but at the same time you sometimes
have to be creative in how to accomplish what you're after.
Jonas
jordah ferguson wrote:
> sorry rob, but i'm not getting you.
> how would i copy these keys? coz the only way i know would be using
> db_insert(). what do you mean they are unique. db_find_key returns an
> integer eg1 or 3. isn't it possible it could interfere with other keys
> in other tables.
>
> sorry, rob. i just don't know how the database.e library works? I know
> how to use it and it is the key component of my application. please be a
>
> bit less technical.
>
3. RE: EDS cry out!!!! Rob, Andy Sepa, anyone]
> -----Original Message-----
> From: jordah ferguson [mailto:jorfergie03 at yahoo.com]
> sorry rob, but i'm not getting you.
> how would i copy these keys? coz the only way i know would be using
> db_insert(). what do you mean they are unique. db_find_key returns an
> integer eg1 or 3. isn't it possible it could interfere with
> other keys
> in other tables.
>
> sorry, rob. i just don't know how the database.e library
> works? I know
> how to use it and it is the key component of my application.
> please be a
> bit less technical.
What Rob is suggesting is leaving your original table untouched, and only
copy the key values to a new table. The structure of an EDS table is to
have { key, data } for each record of the table. To actually access a
record, you use db_find_key(), which returns a record number (just an index
to point to the record within the table). However, all key _values_ will be
unique within the table. Then you'll have an original table, and another
table with just the keys, that you could use to reference the old table.
You should never permanently store record numbers, since these often change
whenever a record is inserted or deleted. Only key value is
important/necessary/sufficient.
This is [sorta] how relational databases work. Records in table A can
reference records in table B using the key values of table A (thus defining
a relation between the two tables). Of course, you'll need to structure the
data in an EDS record to suit your purposes, since this isn't done for you.
By storing the data in one place, you can reduce the size of your file, as
well as eliminate errors that could be caused if data is stored in two
places, and only one is changed, etc.
The keys could, indeed conflict with other keys in other tables. Now you're
getting into database design (and probably deeper, considering EDS doesn't
really enforce a relational [or any other] scheme). Maybe if you told us a
bit more about why you're copying so many records. Do you need to do this
often, or is this an occaisional thing? Perhaps there's a better way to
organize the data.
Matt Lewis
> Robert Craig wrote:
> > No, I didn't mean to suggest that EDS would do anything
> > for you automatically or magically.
> > I just meant that since keys are unique,
> > you could leave the large chunk of data in one place, and
> > just copy the (small) key value around to various tables.
> > You could then retrieve the data any time you want by
> > the usual method: select the table, look up the record by key
> > (it's fast because it uses binary search), then access
> > the (large) data for that record.
4. RE: EDS cry out!!!! Rob, Andy Sepa, anyone]
Rob,
what did you mean? Do you mean that instead of copying the data in the
record i could simply copy the record key to another table and it would
work fine.
for example, if i my db_record_key was jordah in a table called
jordah_table. do you mean i could simply copy this jordah to another
table called robert without the need for transfering the key data?
if so, then this should be added to the documentation? or have i not
read it right?
Good day. Rob
Robert Craig wrote:
> Jordah Ferguson writes:
> > I have a problem, i want to perform copy and move
> > operations of records between database tables.
> > 1) To perform a copy of contents of data from one table to another, i do
> >
> >
> > a for loop, to get each key and its
> > data then insert it in the destination table.
> >
> > 2) To perform a move operation, i do exactly the same as above followed
> > by deleting the original record from the first table. Right?
>
> Sounds reasonable.
>
> > The above operations would work fine for me if one record
> > was being moved or saved, but moving 20 to 30 records
> > records which inturn have over 30kb of data can tend to be very sloww!!!
> > is there a better and faster way of copying and moving data
> > between tables?
>
> No.
> I suppose in the future it would be possible for EDS to have a
> move operation that would not actually copy the data,
> but would simply copy the pointers to the key and data portion,
> creating a new record in another table.
> Of course, you could do something similar today by not
> copying the 30K data, but just copying the key value into a record
> in the other table. The key can be used to quickly locate and retrieve
> a record.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
