Tim

>Actually, no, this is just the length of any indexed word, i.e. the engine
>will simply truncate any word that is larger than this setting. The actual
>determination of which words to index based upon length is done by the word
>generator. The default word generator has a minimum word length of 3 and a
>maximum of 30 and a fixed stop words list of 144 common noise words. You
>can change all of this by writing a custom word generator, which is simply
>an external EDB module (DLL) that handles the word generation in a custom
>fashion.

From this and other comments about user defined functions I get the impression it'll no longer be possible to compile the whole shebang into one .exe

While external dll's may give more flexibility one of the joys of DBISAM is being able to produce an app in a  single executable file. Will there be ways to still accomplish this?

>Well, hopefully not too many will want to "fall back".

I'm hoping not to but I always like a "just in case"


>If you're referring to things like IF EXISTS, then no, I don't agree at all.
>It is much more flexible and extensible to be able to query the information
>schema to see if something exists than it is to add IF [NOT] EXISTS to every
>single SQL DDL statement in the product. It is also much more powerful,
>when combined with the ability in a procedure to make multiple branching
>decisions based upon information in the information schema, such as "if the
>table version is 2, then do this, else if the table version is 3 and the
>number of columns is 4, then do this", etc. You can very easily create one
>procedure that upgrades the structures of all tables, etc. in an entire
>database in one shot. This type of expressive functionality was never
>possible with DBISAM's SQL.

I'll reserve judgement until I see a sample, or better still until I write some code.

Roy Lambert

Roy

Tim will answer this but if you have the source code, instead of coding
DLLs, you can code inside server code producing a single EXE.

Eduardo

Jose


So you have a beta do you?

Roy Lambert

Roy

No, unfortunately I don´t have a beta.

Eduardo

Jose


Ahhhh. So you're guessing to


Roy Lambert

Roy,

<< From this and other comments about user defined functions I get the
impression it'll no longer be possible to compile the whole shebang into one
..exe >>

Yes, if you choose to add external functions/procedures along with any text
filters and/or word generators.  By default, you don't need any of these
things.

<< While external dll's may give more flexibility one of the joys of DBISAM
is being able to produce an app in a single executable file. Will there be
ways to still accomplish this? >>

Not if you want any of the above.  You have to remember that external
functions/procedures and text filters/word generators are now catalog
objects, so it's not the same architecture as DBISAM at all.

<< I'll reserve judgement until I see a sample, or better still until I
write some code. >>

You'll like it.  It's very cool and very simple.  Here's an example of a
simple function that just repeats a string a certain number of times:

CREATE FUNCTION RepeatString ("StringToRepeat" CHAR(30) COLLATE
ANSI_Ordinal,"RepeatCount" INTEGER)
RETURNS CHAR(256) COLLATE ANSI_Ordinal
BEGIN
DECLARE I INTEGER DEFAULT 1;
DECLARE Result CHAR(256) DEFAULT '';

WHILE (I <= RepeatCount) DO
  SET Result=(Result+StringToRepeat);
  SET I=(I+1);
END WHILE;

RETURN Result;

END
DESCRIPTION 'Repeats a string X number of times'

It's about the same number of lines as with Delphi as far as the body of the
function is concerned, and the EDB database manager generates the code for
the parameters, returns clause, and description.  Just the inclusion of
simple looping, if/else/case, and variable declaration/assignment opens up a
whole new world to procedures and functions and means that many, if not all,
that were coded in Delphi previously no longer need to be.  And that doesn't
even begin to cover the native cursor navigation/updating possible in
procedures.

However, word generators and text filters *must* be implemented in an
external DLL, both for performance reasons and because it makes the design
much simpler.

--
Tim Young
Elevate Software
www.elevatesoft.com

Eduardo,

<< Tim will answer this but if you have the source code, instead of coding
DLLs, you can code inside server code producing a single EXE. >>

I wouldn't recommend trying to do so.  You'll just end up with a mess on
your hands since this stuff is not handled in the server but rather in the
core of the catalog functionality in the engine itself.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Yes, if you choose to add external functions/procedures along with any text
>filters and/or word generators.  By default, you don't need any of these
>things.

You will unless you're building in native support for stripping out rtf and html code - or am I missing something (a frequent occurance)

>However, word generators and text filters *must* be implemented in an
>external DLL, both for performance reasons and because it makes the design
>much simpler.

I found it quite easy coding the full text indexing (which I presume you're on about) integral to the exe with DBISAM

Roy Lambert

ps interesting example, not one I can immediately think of a use for but interesting

Tim

Got it, I was thinking like DBISAM instead of ElevateDB (I don´t know yet).

Eduardo

Roy,

<< You will unless you're building in native support for stripping out rtf
and html code - or am I missing something (a frequent occurance) >>

Sure, but this is even easier to deal with in ElevateDB because of the
ability to associate a specific text filter with a specific "type" column.
You couldn't do that in DBISAM.  As for using a DLL instead of an EXE, that
really comes down to a religious issue.  The code is still optimized
Delphi-compiled code just like with DBISAM, and it comes in an easy-to-use
external/word generator/text filter module template (TCustomModule
descendants) that you can start by using File/New and selecting them from
the Object Repository in Delphi.  Think a TWebModule, but for external
modules/word generators/text filters.

<< I found it quite easy coding the full text indexing (which I presume
you're on about) integral to the exe with DBISAM >>

Yes, but I was talking about the *internal* design of ElevateDB, not whether
it is easy for you.

<< ps interesting example, not one I can immediately think of a use for but
interesting >>

It was just an example of something very stupidly simple that you couldn't
do with DBISAM without a recompile and some messing about with the database
server.  Also, it won't be in the initial release, but there really isn't
anything stopping us from allowing for multiple languages in the stored
procedures.  It would be very easy to do basic Pascal and VB versions since
the only thing that would need to change is the parsing.

--
Tim Young
Elevate Software
www.elevatesoft.com