Questions...
Brian Dukes
Questions aimed mainly at Sequiter, but perhaps others may want to add to
the list!!!
I've experienced dBase and CA-Clipper (with other RDD's as well) for my
xBase knowledge and now i'm converting a Clipper app to C++ with codebase
6.2, I notice some fundamentals missing.
Now I appreciate that *I* have the *FULL* source code to CodeBase, so
anything that is missing I can code myself for myself; but some of the
fundamentals *I* think are missing ought to be in the core product.
1. In dBase/Clipper you have a command SET DELETED, which allows you to
toggle on or off the ability to SKIP into DELETED records or to
AUTOMATICALLY hide them from you. This is very handy, and you do not
need to have an index with a ".NOT. DELETED()" expression. For small
tables, it is feasible that there may be NO index required.
2. A Tag4::KeyCount() & Tag4::KeyPosition() feature would be "real" handy!,
this would allow you to correctly draw scroll bars down a list of
records; because you know how many records are there and where you
currently are!
3. A Tag4::KeyAdd() & Tag4::KeyDrop() feature would allow you to build an
index based on "user" selected criteria; You would also need the ability
to build an empty tag to do this, so I guess a Tag4::Clear() type
command would also be handy.
4. A Tag4::Scope(), Tag4::ScopeTop() & Tag4::ScopeBottom() function set
would allow you to scope a portion of a database, so that a Data4::top()
would go to the ScopeTop() rather than bof(), but bof() would be true,
because logically ScopeTop() would be the top of the file.
5. The ability to extend the expressions that are parsed by the index engine
or the query engine for adding user-defined functions to index keys,
obviously using a well defined API for developing such functions.
6. A Data4::WildSeek() function so you can wild-card match expressions, if
you are interested I have a function which I used in my Clipper
applications written in C, that I used to create Wildcard searchs.
I'm sure others have got more to add to this, it would be interesting to see
if there is any support from other users for some of the above ideas. If I
know Sequiter WILL do them, I can wait. If I know Sequiter WILL-NOT do
them, then i'll do them myself at some point. If I knew Sequiter would
include MY enhancements in future releases, i'd do them now!
So folks lets have some input, lets see some ideas being generated here!!
Brian.
--
Brian Dukes - email: bdu...@crox.demon.co.uk
http://www.crox.demon.co.uk/cellar/
Error 1010: Wit error, tagline humour not found
David "MacMan" Merryweather
Brian Dukes wrote:
> Questions aimed mainly at Sequiter, but perhaps others may want to
> add to
> the list!!!
>
> I've experienced dBase and CA-Clipper (with other RDD's as well) for
> my
> xBase knowledge and now i'm converting a Clipper app to C++ with
> codebase
> 6.2, I notice some fundamentals missing.
>
> Now I appreciate that *I* have the *FULL* source code to CodeBase, so
> anything that is missing I can code myself for myself; but some of
> the
> fundamentals *I* think are missing ought to be in the core product.
>
> 1. In dBase/Clipper you have a command SET DELETED, which allows you
> to
> toggle on or off the ability to SKIP into DELETED records or to
> AUTOMATICALLY hide them from you. This is very handy, and you do
> not
> need to have an index with a ".NOT. DELETED()" expression. For
> small
> tables, it is feasible that there may be NO index required.
** Yes, but I would go a step further and add a SET FILTER.. that
controlled all results for SKIP.( BTW - I'm from the FoxPro world and a
BIG TIME Macintosh Person. )
>
>
> 2. A Tag4::KeyCount() & Tag4::KeyPosition() feature would be "real"
> handy!,
> this would allow you to correctly draw scroll bars down a list of
> records; because you know how many records are there and where you
>
> currently are!
AMEN BROTHER - I had to write a rinky-dink stepping skipping counting
routine to find this information out.
>
>
> 3. A Tag4::KeyAdd() & Tag4::KeyDrop() feature would allow you to build
> an
> index based on "user" selected criteria; You would also need the
> ability
> to build an empty tag to do this, so I guess a Tag4::Clear() type
> command would also be handy.
This can be done by type casting a memory partition which is (sizeof
(TAG4) * (numOfTags + 1))Build the tag sturcture in memory and use
i4TagAdd or i4Create.
>
>
> 4. A Tag4::Scope(), Tag4::ScopeTop() & Tag4::ScopeBottom() function
> set
> would allow you to scope a portion of a database, so that a
> Data4::top()
> would go to the ScopeTop() rather than bof(), but bof() would be
> true,
> because logically ScopeTop() would be the top of the file.
You lost me on that one...
>
>
> 5. The ability to extend the expressions that are parsed by the index
> engine
> or the query engine for adding user-defined functions to index
> keys,
> obviously using a well defined API for developing such functions.
You want a DBase Interpreter... Not gonna do it, wouldn't be prudent
... Your using C to get away from
the speed or lack of. If your app needs this, write a custom stap on
file and API that the index routines can use to maintain the custom
searches.
>
>
> 6. A Data4::WildSeek() function so you can wild-card match
> expressions, if
> you are interested I have a function which I used in my Clipper
> applications written in C, that I used to create Wildcard searchs.
Oh yes... Wild cards are very nice.
>
>
> I'm sure others have got more to add to this, it would be interesting
> to see
> if there is any support from other users for some of the above ideas.
> If I
> know Sequiter WILL do them, I can wait. If I know Sequiter WILL-NOT
> do
> them, then i'll do them myself at some point. If I knew Sequiter
> would
> include MY enhancements in future releases, i'd do them now!
>
> So folks lets have some input, lets see some ideas being generated
> here!!
>
> Brian.
> --
> Brian Dukes - email: bdu...@crox.demon.co.uk
> http://www.crox.demon.co.uk/cellar/
>
> Error 1010: Wit error, tagline humour not found
--
David "MacMan" Merryweather
Creative Education Institute - Waco, Texas USA
(tele-voice) 254.751.1188 x 115
(tele-fax ) 254.751.1199
-------------------------------------------------
You're born, you code, you die...
Code while you can, it doesn't last forever..
-------------------------------------------------
Brian Dukes
"David \"MacMan\" Merryweather" <dav...@cei-waco.com> wrote:
>Brian Dukes wrote:
>> 4. A Tag4::Scope(), Tag4::ScopeTop() & Tag4::ScopeBottom() function
>> set
>> would allow you to scope a portion of a database, so that a
>> Data4::top()
>> would go to the ScopeTop() rather than bof(), but bof() would be
>> true,
>> because logically ScopeTop() would be the top of the file.
>
>You lost me on that one...
lets suppose we have a database with a name field, the records look like
this :-
..
..
ROBERTS; T
SIMPSON; J
SIMMONDS; A
SMITH; A
SMITH; B
SMITH; J
SMITH; J
SMITHE; A
STORRIDGE; B
..
..
Ok, now the TAG has a key order of NAME, but this database has 500,000
names in it, its a big marketting database (for example).
Ok, conventionally, SET FILTER TO ... would allow you to pick up on all
names beginning "SMITH", be hell we know thats not quick at the best of
times.
By "scoping" the index, we are setting a logical top/bottom marker on the
index, so a gotop() would in effect do a seek("SMITH"), where a go bottom
would in effect seeklast("SMITH"), and you could skip through all the skips
in the normal way.
Believe me I have used RDD's (replacable database drivers) in CA-Clipper
that have the ability to scope part of an index, and it is VERY VERY handy.
>
>
>>
>>
>> 5. The ability to extend the expressions that are parsed by the index
>> engine
>> or the query engine for adding user-defined functions to index
>> keys,
>> obviously using a well defined API for developing such functions.
>
>You want a DBase Interpreter... Not gonna do it, wouldn't be prudent
>... Your using C to get away from
>the speed or lack of. If your app needs this, write a custom stap on
>file and API that the index routines can use to maintain the custom
>searches.
NO NO NO!!!!
Lets suppose I have a C/C++ function called WildMatch that returns a TRUE
(1) or a FALSE (0) if the string passed into it matches a wildcard
expression.
Now, in Clipper I could build an index for a FOR expression that allowed me
to in effect only index records that match my criteria.
With CodeBase I can still do that, but ONLY with expressions which are coded
into the expression engine.
What *I* want is the ability to TELL the expression engine that when parsing
the tag expression and it comes across a function called "WILDMATCH" then
it should call my user-defined C function ... obviously in a defined way,
accepting defined parameters and returning a defined type.
>
>
>>
>>
>> 6. A Data4::WildSeek() function so you can wild-card match
>> expressions, if
>> you are interested I have a function which I used in my Clipper
>> applications written in C, that I used to create Wildcard searchs.
>
>Oh yes... Wild cards are very nice.
Yes, so how do you do them in CodeBase ???
Steve Brownlow
Brian Dukes <bdu...@crox.demon.co.uk> wrote in article
<33e1bd36...@crox.demon.co.uk>...
> Questions aimed mainly at Sequiter, but perhaps others may want to add
to
> the list!!!
>
> anything that is missing I can code myself for myself; but some of the
> fundamentals *I* think are missing ought to be in the core product.
>
> 1. In dBase/Clipper you have a command SET DELETED, which allows you to
> toggle on or off the ability to SKIP into DELETED records or to
> AUTOMATICALLY hide them from you. This is very handy, and you do not
> need to have an index with a ".NOT. DELETED()" expression. For small
> tables, it is feasible that there may be NO index required.
Codebase for accessing Xbase data. So I am lucky that I only need to get my
file handler routines working perfectly, then I can forget them for a
couple of years.
With Codebase 5.1, I ALWAYS used a ".NOT.DELETED()" filter for all tags.
I then discovered this year that that STOPs most products from optimising
their access of those files, causing large performance loss with large
files.
So I removed all those filters, and implemented my own logic to bypass
deleted records. It was quite difficult to get this logic working right in
all conditions, particularly when re-adding a record with the same key as
one that was previously deleted.
I do recommend that as the right approach, but I agree that if Sequiter
could provide a simple option such as you suggest (and as Foxpro has), it
would make things much simpler.
We use Codebase and Foxpro not for backward compatibility with old dbase
features, but as a fast and cheap alternative to Oracle, Sybase, etc.
I pity anyone who has to make many changes to the standard Codebase.
Codebase 6.x has so much preprocessing and so few comments that the source
is very difficult to read, and if the last API change is any guide, there
might be significant API changes again when 7.x comes around.
Brian Dukes
"Steve Brownlow" <brow...@mpx.com.au> wrote:
[snip SET DELETED suggestion]
>
>I have 2500 Cobol programs using my file handler routines, which use
>Codebase for accessing Xbase data. So I am lucky that I only need to get my
>file handler routines working perfectly, then I can forget them for a
>couple of years.
And a mechanism that i've followed in other applications; this allows far
more flexibility as well ... if your application needs to support another
data-driver, then all you need to do is modify the core (or inherit/derive
from it).
>
>With Codebase 5.1, I ALWAYS used a ".NOT.DELETED()" filter for all tags.
>I then discovered this year that that STOPs most products from optimising
>their access of those files, causing large performance loss with large
>files.
Wasn't aware of that, i've been using several different FoxPro style
data-drivers with Clipper, most of which come with a rushmore style querying
system, that use the index to find complex queries.
>So I removed all those filters, and implemented my own logic to bypass
>deleted records. It was quite difficult to get this logic working right in
>all conditions, particularly when re-adding a record with the same key as
>one that was previously deleted.
>I do recommend that as the right approach, but I agree that if Sequiter
>could provide a simple option such as you suggest (and as Foxpro has), it
>would make things much simpler.
>
>I pity anyone who has to make many changes to the standard Codebase.
>Codebase 6.x has so much preprocessing and so few comments that the source
>is very difficult to read, and if the last API change is any guide, there
>might be significant API changes again when 7.x comes around.
Hmm, and if I *knew* sequiter would NEVER entertain the ideas of adding it,
I would do it myself. In my opinion though, the best people to do it are
Sequiter, they know the code inside out, and they know what the effects of
inserting code will be like; Personally I would have thought it would be
relatively trivial for a programmer with in depth knowledge of the CodeBase
source code to do .... my problem is I just don't have the time to start to
get close to the internals of CodeBase.
Ok I here you C++ guys shouting at me, it's easy! Yes I know, I can derive
from the Data4 class and create my own, and thats fine for me; but i'm not
selfish, I think all CodeBase users should benefit from this.
Bri.
David "MacMan" Merryweather
Brian Dukes wrote:
> cst...@sequiter.com (Cam Stobbe) wrote:
>
> >>Brian Dukes wrote:
> >>
> >>> 1. In dBase/Clipper you have a command SET DELETED, which allows
> you
> >It would be nice, but of course CodeBase is a low-level API, so
> >instead of doing it automatically, CodeBase gives you the tools to to
>
> >the same things that Clipper does behind the scenes.
>
> Well that's obviously one way of looking at it, and if developers
> took the
> same opinion you could argue that fopen(),fread(),fwrite() & fclose()
> are
> low-level file API's, and with these you can build an ORACLE server!
>
> In my opinion CodeBase is a Database Engine, it should (and for the
> most
> does) provide me with hassle free development of database
> applications. My
> suggestions do not detract *any* from the functionality of CodeBase
> nor make
> it anything but a database engine; they merely enhance its usefulness
> to
> the average developer.
My thought was more along the lines of sequiter adding a "delete"
setting in the code4 or data4 structure and then altering all the
codebase routines that this might effect... My customers have no
desire to code the enhancements that they would like to see in my
software, why should we be turned away and expected to do the same...
>
>
> >
> >Here is a function you can use that will do it:
> >int d4skipND(DATA4 *data, long rec) // (skip to not deleted)
> > { int rc = d4skip(data,rec);
> > while (rc == r4success)
> > { if (!d4deleted(data))
> > break;
> > else rc = d4skip(data,1L);
> > }
> > return rc;
> > }
> >
> >I think this should skip to the next deleted record, but I haven't
> >tried it out.
>
> Obviously, try d4skipND(dbf,-1) <GRIN>, what about a top() and
> bottom()
> function, seek needs to be altered as well ... like I said for an
> average
> programmer this is stuff that ought to be built into the core of
> CodeBase.
>
> >
> >>> 2. A Tag4::KeyCount() & Tag4::KeyPosition() feature would be
> "real"
> >>> handy!,
> >>> this would allow you to correctly draw scroll bars down a list
> of
> >>> records; because you know how many records are there and where
> you
> >>> currently are!
> >>
> >>AMEN BROTHER - I had to write a rinky-dink stepping skipping
> counting
> >>routine to find this information out.
> >
> >There'r no function to get the number of entries in a tag, but
> >d4position() will give you a relative position within the currently
> >selected tag.
>
> Geee Wizz, Great so now I can draw a scroll bar, but I cannot easily
> find
> out how many records I have in my index. For an index with a for
> .not.
> deleted() condition, knowing the number of entries in a tag would
> allow you
> to know how many LIVE records you have in the database.
>
> And does d4position() take into account deleted records, I don't
> think so;
> so again our custom skipper must also work out the relative
> position!!!
>
> >
> >>> 5. The ability to extend the expressions that are parsed by the
> index
> >>> engine or the query engine for adding user-defined functions to
> index
> >>> keys, obviously using a well defined API for developing such
> functions.
> >
> >You can use code4calcCreate() to create you own dBASE functions, if
> >that's what you mean.
>
> Not quite, but almost!
>
> Bri.
> --
> Brian Dukes - email: bdu...@crox.demon.co.uk
> http://www.crox.demon.co.uk/cellar/
>
> Error 1010: Wit error, tagline humour not found
james...@tpg.com.au
cbTable->setdeleted=true; //false ???
will does the same for the d4skipND(..).
codebase6 has most of the need of clipper/foxpro...
only need to use via C/C++ .
cheers!
On Thursday, 31 July 1997 15:00:00 UTC+8, Brian Dukes wrote:
> Questions aimed mainly at Sequiter, but perhaps others may want to add to
> the list!!!
>
> xBase knowledge and now i'm converting a Clipper app to C++ with codebase
> 6.2, I notice some fundamentals missing.
>
> anything that is missing I can code myself for myself; but some of the
> fundamentals *I* think are missing ought to be in the core product.
>
>
> 1. In dBase/Clipper you have a command SET DELETED, which allows you to
> toggle on or off the ability to SKIP into DELETED records or to
> AUTOMATICALLY hide them from you. This is very handy, and you do not
> need to have an index with a ".NOT. DELETED()" expression. For small
> tables, it is feasible that there may be NO index required.
>
> this would allow you to correctly draw scroll bars down a list of
> records; because you know how many records are there and where you
> currently are!
>
> index based on "user" selected criteria; You would also need the ability
> to build an empty tag to do this, so I guess a Tag4::Clear() type
> command would also be handy.
>
> would allow you to scope a portion of a database, so that a Data4::top()
> would go to the ScopeTop() rather than bof(), but bof() would be true,
> because logically ScopeTop() would be the top of the file.
>
> or the query engine for adding user-defined functions to index keys,
> obviously using a well defined API for developing such functions.
>
> you are interested I have a function which I used in my Clipper
> applications written in C, that I used to create Wildcard searchs.
>
>
> if there is any support from other users for some of the above ideas. If I
> know Sequiter WILL do them, I can wait. If I know Sequiter WILL-NOT do
> them, then i'll do them myself at some point. If I knew Sequiter would
> include MY enhancements in future releases, i'd do them now!
>
> So folks lets have some input, lets see some ideas being generated here!!
>
> Brian.