1. data base access
- Posted by George Walters <gwalters at sc.rr.com> Aug 03, 2001
- 484 views
Rob, I think I have an understanding of the data base tools you have provided and since you are working on 2.3 I would like to offer for your consideration an approach with which I am familiar. You have suggested that the 600+ data files I have should be organized into separate data bases by module. (i.e AR, AP,IC,GL...etc.). Here's the issue. In a rather complex program such as order entry we have 22 different files open at one time from AR (customers), IC (part numbers from inventory), OP (orders), PU (purchasing), SA (sales history of customer pricing) and on and on. This program would span 4 or 5 data bases with the 22 tables. So not only would we be switching tables but also data bases. Your concept of 'current data base' and 'current table' would be useless here but fine for other programs (i.e inventory maintenance or printouts). If I have, in this order entry program, just read the customer record and now need to read an inventory record here's what I would have to do 1. db_select (IC) 2. db_select_table(ic_master) 3. db_find_key(somePartkey) 4. db_record_data(somePartRecordNbr) This would be done over and over through the 22 tables, not a very direct approach. It would seem that the db's and tables' could be kept in a sequence internally (built internally as the tables are opened) and the reads could be done as follows ic_record = db_read( db_opened_table[x], item_key) -- with one read and items 1-4 be taken care of internally. if EOF [bb_opened_table[x]] -- item not found, keeping the return code separate from the data read bla,bla saves striping it out. end if There could also be additional functions such as ic_record = db_readnext(db_opened_table[x]) -- to provide the next record in sorted order by keys. useful for reports and displays ic_record = db_readprev(db_opened_table[x]) -- to provide the previous record in sorted order by keys 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) If db_opened_table[x] is "" then the functions would refer to the 'current db and 'current table' such as a read of ic_record = db_readnext("") --would refer to the 'current' db and table. This could actually be simplified by the old concept of file number that would be returned by the open where we could just do: ic_record = db_read(x,somePartKey) --where x would be used internally to index into the db_opened_table[x] I could probably write these functions but they would be better dealt with internally in EU....I would say that the current functions you have should remain in place so as not to break current programs being used. I have probably not stated this properly in the flavor and syntax of EU but hopefully you get the idea and can do something with it. thanks... ...george
2. Re: data base access
- Posted by George Walters <gwalters at sc.rr.com> Aug 03, 2001
- 463 views
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 ----- Original Message ----- From: "Jonas Temple" <jktemple at yhti.net> To: "EUforum" <EUforum at topica.com> Subject: 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 > > > > > > >
3. Re: data base access
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 03, 2001
- 468 views
George Walters writes: > the 'current table' issue would still be a problem in > a program reading from so many different data bases. EDS was designed with the idea of having a "current table" and a "current database". This was done mainly to reduce the number of arguments to be passed on the various database operations. If you are randomly accessing many different tables, this approach won't be as nice as one where you specify the database and table on every call. I doubt that performance will be an issue, since db_select() takes only a few microseconds to choose a new database, and no file is opened or closed. db_select_table() reads in 4 bytes per record from the table, but this data is likely cached in memory, so no disk access would be required. Again, we are talking microseconds. If you are getting input data from a user, then you will spend a lot longer waiting for the user to type one keystroke than you will spend doing a typical database update. If Jonas has alternate routines that let you avoid explicitly selecting a database and table, then you should probably use them. I don't plan to add routines like that to EDS. I'd rather that other people add extra layers of code to suit their needs and their taste. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
4. Re: data base access
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 03, 2001
- 506 views
Jonas Temple writes: > Rob, hoping that you read this, I would like to again > request a thought on indexes withing database.e. > What do you think? I don't intend to do any major EDS enhancements, or designing, until some time after 2.3 is out. Maybe someone else can play around with indexes. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
5. Re: data base access
- Posted by George Walters <gwalters at sc.rr.com> Aug 06, 2001
- 462 views
Rob, and Jonas, in reading your responses there is a concern I have from both of your approaches, namely that every time a select_table() is performed the entire file has to be read. This wouldn't seem to support any substantial software application. The 22 files I've mentioned for an 'order entry' program represent 20-100Mbytes of data, when you consider 3-5k customers, 50k inventory, 2+ stocking locations... etc. Jonas, if this is happening on your file server just to retreive one record from several files, I don't see how it could support multiple users. The server would be scanning the same files front to end over and over... So what would anyone suggest for a reasonable approach. Perhaps mysql would be a better approach? I'm kinda at a confused point now. Rob, I'm thinking that this type of application is beyond what you have intended for your language to support. It seems so good on the things I've touched so far, but appears falls short on file access, but perhaps you have not intended for it to support this type of application. Could you comment on this? thanks... george ----- Original Message ----- From: "Robert Craig" <rds at RapidEuphoria.com> To: "EUforum" <EUforum at topica.com> Sent: Friday, August 03, 2001 12:03 PM Subject: Re: data base access > > George Walters writes: > > the 'current table' issue would still be a problem in > > a program reading from so many different data bases. > > EDS was designed with the idea of having > a "current table" and a "current database". > This was done mainly to reduce the number of arguments > to be passed on the various database operations. > If you are randomly accessing many different tables, > this approach won't be as nice as one where you specify > the database and table on every call. > > I doubt that performance will be an issue, > since db_select() takes only > a few microseconds to choose a new database, and no file > is opened or closed. db_select_table() reads > in 4 bytes per record from the table, but this data is likely > cached in memory, so no disk access would be required. > Again, we are talking microseconds. > If you are getting input data from a user, then you will > spend a lot longer waiting for the user to type one keystroke > than you will spend doing a typical database update. > > If Jonas has alternate routines that let you > avoid explicitly selecting a database and table, > then you should probably use them. I don't plan to > add routines like that to EDS. I'd rather that > other people add extra layers of code to > suit their needs and their taste. > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > > > >