Tim

>You're part of Team Elevate, you can have the source code now if you want.
>I think you'll see that it is a little more complicated than you might
>think.

We need rules on this newgroup to prevent obscenities like that offer.

Roy Lambert

Roy,

<< We need rules on this newgroup to prevent obscenities like that offer. >>



Seriously, though, if you want the source code just email Sam and she'll set
you up.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


If I ever manage to make enough money to be able to take a couple of months of so I have a chance of understanding the code I might do that. Whilst I know you write good code its not in my format (I hate the hanging Borland style) and there's a lot of it. This is why in my initial post I said after a lottery win - I'd be a man of leisure then and have the time to do it justice.

Roy Lambert

> Whilst I know you write good code its not in my format (I hate
> the hanging Borland style) and there's a lot of it.

http://jedicodeformat.sourceforge.net/


--
David Cornelius
CorneliusConcepts.com

David


Thanks for the link. I'm currently using DelForEx in GExperts (I've used DelForEx for ages). One thing it won't do, quite rightly, is remove line breaks if you add them manually (surplus blank lines between procedures are zapped). Hence if someone has used the Borland style DelForEx will not bring the "then begin" onto the same line. Does the Jedi one?

Roy Lambert

> Thanks for the link. I'm currently using DelForEx in GExperts (I've
> used DelForEx for ages). One thing it won't do, quite rightly, is
> remove line breaks if you add them manually (surplus blank lines
> between procedures are zapped). Hence if someone has used the Borland
> style DelForEx will not bring the "then begin" onto the same line.
> Does the Jedi one?

I believe it does, but it's been a while since I used it.  I once used
DelForEx as well; the Jedi one is incredibly powerful, compared.

--
David Cornelius
CorneliusConcepts.com

Tim,

If I've got  right, this discussion is about  incremental metadata replication.  This is
what I am planning to do:

1. Suppose the program used to to design and manage the databases could log the SQL's
generated for every metadata change.
2. When the changes needs to be replicated they are  deployed as a script  with a version
number, which can be treated as the version of the database.
3. The update script is executed  before the DB is opened.   
4. When the database is openned by an application, the app checks the dbversion it
requires against the version in the db.   This can be easily done form code, but it would
be useful to have a TEDBDataBase.OpenRequiredDBVersion(<dbversion>; ExactmatchRequired:
boolean) method.
5. When more then one apps are using the same db,  somehow needs to be checked if they are
all compatible with the new version of the db before the changes are applied.  For that I
would have every version of the  applications  and the DB version they require registered
in a separate db in a separate catalog . The script which automates deploying all changes
(exe, metadata ...) could store all updates (scripts, exe ...  ) there.
6 After a DB restore all changes can be autamitcally applied again.

Of course I will have to write my own DBManager, unless you decide (and find the time) to
include SQL logging into EDBManager.


---

About the singlefile db question:  you could try  SingleFileSytem, SolidFileSystem or
something similar. This approach would require probably only very small changes. Though it
may effect performance much more. Or not at all. To tell the truth when I first read
about EDB I have discarded it because of not having a single file database, and only your
willingness of porting EDB for WinCE made me take a closer look at EDB again. (: Which I
am glad I did  Your explanation is perfectly clear why it is so, but I am sure that,
the first reaction of many experienced programmers is similar to this: "This is the way it
was in the old days, no serious new SQL engines are like this any more." If you want to
market EDB as a viable alternative of the widely known SQL engines, I think this is a kind
of must have.     

Regards,
Leslie

Leslie,

<< Of course I will have to write my own DBManager, unless you decide (and
find the time) to include SQL logging into EDBManager.  >>

The EDB Manager already has SQL logging (it's called SQL History), and the
default is 30 statements, but you can increase the number of statements
logged to anything that you want.

I'll see about possibly segmenting the logging by database name, which would
help immensely with what you're proposing.

<< About the singlefile db question:  you could try  SingleFileSytem,
SolidFileSystem or something similar. This approach would require probably
only very small changes. Though it may effect performance much more. Or not
at all. To tell the truth when I first read about EDB I have discarded it
because of not having a single file database, and only your willingness of
porting EDB for WinCE made me take a closer look at EDB again. (: Which I am
glad I did  Your explanation is perfectly clear why it is so, but I am
sure that, the first reaction of many experienced programmers is similar to
this: "This is the way it was in the old days, no serious new SQL engines
are like this any more." If you want to market EDB as a viable alternative
of the widely known SQL engines, I think this is a kind
of must have.  >>

I really don't want to get into this discussion again.  If you do a search
on these newsgroups:

http://www.elevatesoft.com/newsgrp?action=search&group=0

you will find thread after thread about why we don't use a single file
database.  And, honestly, "everyone does it" is not a valid reason to do
anything.  There are technical reasons for, and against, using a single-file
database format, and just doing it for the heck of it is both silly and can
kill the performance of a file-sharing, multi-user database (which both EDB
and DBISAM provide) very quickly.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

<<The EDB Manager already has SQL logging (it's called SQL History), and the
default is 30 statements, but you can increase the number of statements
logged to anything that you want.

I'll see about possibly segmenting the logging by database name, which would
help immensely with what you're proposing.>>

Would be great.


<<And, honestly, "everyone does it" is not a valid reason to do
anything.  There are technical reasons for, and against, using a single-file
database format, and just doing it for the heck of it is both silly and can
kill the performance of a file-sharing, multi-user database (which both EDB
and DBISAM provide) very quickly.>>

I think you did not  get my point.  You are concentrating on the technical issues, I am
not arguing with you there.  What I  have  tried to bring to your attention is the
marketing/business aspects of it. Not having a single file database puts EDB into the
wrong group of engines in the minds of many programmers. EDB clearly has the potential to
be more then a modern DBISAM replacement,  it may become contender for widely used SQL
engines. (: v3.x or v4.x It is really up to your business model, what kind of costumers
you would like to attract.

Also  those people who are requesting single file database probably do not need the
features which  are against having it. You could make it as an option (as firebird does):
"If you do not need these special features .... " I made peace with the way it is, and
there are many features which are much more important for me, but I still think  testing
how a 3rdparty Single File library would effect performance is worth a try sometimes. And
I still think that it is an important factor in how EDB is viewed. Which probably will
effect your sales at some point.


<<I really don't want to get into this discussion again.>>

Do not worry, me neither. So please do not spend your time on answering me. (I really
mean it!)

Regards,
Leslie    

Leslie,

<< I think you did not  get my point.  You are concentrating on the
technical issues, >>

Of course I am.  A single-file database format would simply not work for EDB
given its current architecture.  That's a fact, and there's no getting
around it.  You cannot do the type of multi-user locking that we do with a
single-file database format, and still maintain any semblance of
performance.

<< I am not arguing with you there.  What I  have  tried to bring to your
attention is the marketing/business aspects of it. Not having a single file
database puts EDB into the wrong group of engines in the minds of many
programmers. EDB clearly has the potential to be more then a modern DBISAM
replacement,  it may become contender for widely used SQL engines. (: v3.x
or v4.x It is really up to your business model, what kind of costumers
you would like to attract. >>

I'm sorry, but I don't think that the file format is the #1 issue that
developers care about when looking at a product.  Anyone can do a
single-file database format, and it's not a big deal *by itself*.  It's all
of the other issues like performance and locking that get in the way.

<< Also  those people who are requesting single file database probably do
not need the features which  are against having it. You could make it as an
option (as firebird does): "If you do not need these special features .... "
I made peace with the way it is, and there are many features which are much
more important for me, but I still think  testing how a 3rdparty Single File
library would effect performance is worth a try sometimes. And I still think
that it is an important factor in how EDB is viewed. Which probably will
effect your sales at some point. >>

First of all, just adding a single-file library underneath the engine does
absolutely nothing for EDB except remove the multi-user, file-sharing
capabilities and permitting EDB to only be used as a single-user or server
database engines, regardless of any marketing implications.

Secondly, we have already stated numerous times publicly that we are working
on an enterprise version of the ElevateDB Server that will indeed have a
single-file database format and will *only* be used as a server engine.
However, I try not to mention this in the context of a discussion of EDB
because it muddies the waters with respect to any discussion of the
*current* EDB engine.

Finally, as far as marketing is concerned.  We do not, nor have we ever,
been overly concerned with marketing because we believe that trying to drive
product development in this way is a disaster.  It results in companies
spending huge amounts of time on features that have very little payoff.
This is obvious by the way these discussions are structured.  There's always
the dire warnings about "how people view the product" and "whether people
will take it seriously" with no regard to actual facts to back up such
statements.  In these cases, and I include you in this case, we are
essentially dealing with people projecting their own personal desires on to
a group of people that don't actually exist.  And I don't mean that as an
insult.  It is a natural thing to do, and we all do it.  However, it is our
job to look at such statements with a rational eye and realize what
percentage is truth and what percentage is personal enhancement request.
Our product development is driven by prioritizing the feature requests by
potential and existing customers, and is backed up by *actual feature
requests* that we can keep track of and use to gauge the amount of desire
for a particular feature.  And, as always, we balance these requests against
what is both technically feasible, and whether we will actually deliver on
the feature.  As already stated, it really doesn't do much good to add a
feature that will result in lesser performance and will exclude a segment of
our already existing customer base.

--
Tim Young
Elevate Software
www.elevatesoft.com