David


I've moved it from the extensions ng so it doesn't get to cluttered up.

>I guess I figure that if it's a standard that has gone through
>extensive review by many highly intelligent and experienced
>industry-smart people (which is what standards have to do to become
>standards), then even if I don't completely understand the rationale
>behind it, there must be some good reasons for it and someday I'll
>probably learn about it.

That's where I differ. I don't like taking things of that nature on trust

>There's a good article out there somewhere

If you ever spot it again please post the url.

>You know, it's almost sounding like DBISAM was somewhat hurtful in that
>it provided too many "convenience" features which led to poor
>programming habits!

Hmmm so DROP TABLE IF EXISTS is poor programming?

But then again, DBISAM was originally a BDE
>replacement right? Now with EDB, we're moving into the realm of
>serious database engines (more or less) and we should expect different
>things of it.

Are you telling me mine and all those other's apps using BDE or DBISAM weren't serious

>Such as SQL standard adherance.

This is where it gets interesting. I'm not sure any db out there has 100% compliance (Ole can probably give a score for most) and when you add enhancements into the mix.......

>You may not get any closer to satisfactory answer.

Possibly not, but it won't stop me asking

Roy Lambert

>>I guess I figure that if it's a standard that has gone through
>>extensive review by many highly intelligent and experienced
>>industry-smart people (which is what standards have to do to become
>>standards), then even if I don't completely understand the rationale
>>behind it, there must be some good reasons for it and someday I'll
>>probably learn about it.
>
> That's where I differ. I don't like taking things of that nature on trust

That's a good rule of thumb to keep us watchful and sharp.  But I don't have
time to question everything.


>>You know, it's almost sounding like DBISAM was somewhat hurtful in that
>>it provided too many "convenience" features which led to poor
>>programming habits!
>
> Hmmm so DROP TABLE IF EXISTS is poor programming?

Not in its day--and not for DBISAM.  But EDB has different goals: SQL
standard adherance.  It's not terribly difficult to write a function and
change that statement to:   IF TableExists('MyTable') THEN EXECUTE IMMEDIATE
'DROP TABLE "MyTable"'; END IF;   In fact, if you have a bunch of those, you
could probably do a global string replace to change a bunch of them quickly.


> But then again, DBISAM was originally a BDE
>>replacement right? Now with EDB, we're moving into the realm of
>>serious database engines (more or less) and we should expect different
>>things of it.
>
> Are you telling me mine and all those other's apps using BDE or DBISAM
> weren't serious

Good point!     I think I was coming from the fact that DBISAM was a
step up from using the BDE with Paradox or dBASE, but now with practically
every database supporting SQL and having a client/server engine, the bar has
been raised, so-to-speak, and it's important to take note of newer
standards.  It's obvious EDB is marketed beyond just us Delphi folk--and
adherance to SQL standards is important in that respect.


--
David Cornelius
CorneliusConcepts.com

David,

>>It's obvious EDB is marketed beyond just us Delphi folk--and
>>adherance to SQL standards is important in that respect

Agreed. But I think one must distinguish between a standard violation, and an extension.

The only sense in a standard is, that people switching between databases have less trouble
migrating their apps, and spend less time learning and reading. Violations of the standard
make their life harder...so it's a good thing and a sales argument to be standard compliant.

The null issue for example I would consider a standard violation. I don't like the "new"
way, but I see that it's necessary. Others coming from other databases will expect it that
way - and I want Tim to sell as many EDBs as possible, fearing that otherwise I have to
migrate my apps again

BUT things like "IF NOT EXISTS", "UPDATE FROM", adding dates and times, etc. I consider a
extension - meaning that there is nobody hurt if they exist. People coming from other
databases, not knowing them, simply won't use them - fine, no harm done. People planning
to migrate to other databases could always look up if it's a EDB extension - and decide
not to use them. Again, no harm done.

But for the DBISAM porters, and the ones that don't plan to migrate to a non-Elevatesoft
DB unless forced to, these little gadgets mean a real additional value - they are a time
saviour, convenient and therefore also a sales argument. And in many cases, they are not
even difficult to implement. Yes there are workarounds, but why write an own function when
it already exists ? Why writing 10 lines of code, that could be done in one statement ?
Why rewrite a sql statement if it should only do exactly the same afterwards ? I don't
want to know how many hours people spent with that tasks, without anyone (not Tim, not his
customers exspecting standard compliance) gaining anything from it.

I still wonder, why there are really few questions or complaints from the DBISAMers (there
must be a lot of them). Maybe they search this NG and find a Roy posting, or read the
manual and take it just the way it is. Maybe they don't port at all. Maybe they have given
up Delphi programming. Maybe I have used this DB in some alien ways almost no one else
has. I don't know...

Heiko

>>>It's obvious EDB is marketed beyond just us Delphi folk--and
>>>adherance to SQL standards is important in that respect
>
> Agreed. But I think one must distinguish between a standard violation, and
> an extension.
>
> The only sense in a standard is, that people switching between databases
> have less trouble
> migrating their apps, and spend less time learning and reading. Violations
> of the standard
> make their life harder...so it's a good thing and a sales argument to be
> standard compliant.

Good point.

> The null issue for example I would consider a standard violation. I don't
> like the "new"
> way, but I see that it's necessary. Others coming from other databases
> will expect it that
> way - and I want Tim to sell as many EDBs as possible, fearing that
> otherwise I have to
> migrate my apps again

Really?  That surprises me.  How is it a violation?  Maybe I should revisit
the NULL definition.

> BUT things like "IF NOT EXISTS", "UPDATE FROM", adding dates and times,
> etc. I consider a
> extension - meaning that there is nobody hurt if they exist. People coming
> from other
> databases, not knowing them, simply won't use them - fine, no harm done.
> People planning
> to migrate to other databases could always look up if it's a EDB
> extension - and decide
> not to use them. Again, no harm done.
>
> But for the DBISAM porters, and the ones that don't plan to migrate to a
> non-Elevatesoft
> DB unless forced to, these little gadgets mean a real additional value -
> they are a time
> saviour, convenient and therefore also a sales argument. And in many
> cases, they are not
> even difficult to implement. Yes there are workarounds, but why write an
> own function when
> it already exists ? Why writing 10 lines of code, that could be done in
> one statement ?
> Why rewrite a sql statement if it should only do exactly the same
> afterwards ? I don't
> want to know how many hours people spent with that tasks, without anyone
> (not Tim, not his
> customers exspecting standard compliance) gaining anything from it.

I agree--good points.  But Tim can only do so much at once.  So should he
have waited until every DBISAM extension is in before releasing EDB?  Or
give what he can as he's able?  To quote him: "... the reason that these
aren't done yet is because there is a) another way to do the same thing
already, or b) the functionality is considered "nice to have" but not 100%
crucial compared to things like new platform support."

(Now if he's said there are no plans on putting in some of these extensions,
that would be a different discussion.)

I suppose if the bulk target audience was existing DBISAM users, this would
be a big question.  I suspect he was hoping to expand sales by opening the
database up to Visual Studio programmers.

> I still wonder, why there are really few questions or complaints from the
> DBISAMers (there
> must be a lot of them). Maybe they search this NG and find a Roy posting,
> or read the
> manual and take it just the way it is. Maybe they don't port at all. Maybe
> they have given
> up Delphi programming. Maybe I have used this DB in some alien ways almost
> no one else
> has. I don't know...

I would guess a lot of them are staying with DBISAM for a while.  I started
a new project just before EDB 1 came out, so I quickly changed half way
through and didn't have thousands of lines of code to convert.  Another
project, larger and older, is still stuck in DBISAM.  (But I'm not the main
developer on that one anymore.)

Anyway, it's a tough balancing act--there's always going to be people that
miss or need a feature and those have to be balanced with time and market
constraints.  Probably like CodeGear deciding what features to put in the
next version of Delphi...

--
David Cornelius
CorneliusConcepts.com

Heiko,

<< But for the DBISAM porters, and the ones that don't plan to migrate to a
non-Elevatesoft DB unless forced to, these little gadgets mean a real
additional value - they are a time saviour, convenient and therefore also a
sales argument. And in many cases, they are not even difficult to implement.
Yes there are workarounds, but why write an own function when it already
exists ? Why writing 10 lines of code, that could be done in one statement ?
>>

I've addressed this a million times already here on the newsgroups, so
you'll have to read back through the previous threads regarding this
subject.  Obviously some of you either don't believe me when I give my
reasoning, or think that my reasoning isn't valid.  Either way, it doesn't
really matter.  IF [NOT] EXISTS is simply never going to show up in EDB.
It's clutter, pure and simple, and isn't necessary.  EDB provides a rich
scripting environment with IF conditional processing, and *that* is your IF
EXISTS functionality.  It's time to move on and stop re-hashing these same
arguments every week.

<< Why rewrite a sql statement if it should only do exactly the same
afterwards ? >>

Because EDB is a completely different product, and we never stated that
DBISAM compatibility was high.  So, aren't your objections about complete
DBISAM SQL compatibility an issue with your expectations, not anything we
are doing ?

<< I don't want to know how many hours people spent with that tasks, without
anyone (not Tim, not his customers exspecting standard compliance) gaining
anything from it. >>

Incorrect.  We do gain quite a bit from not having IF EXISTS scattered
everywhere.  The EDB code is cleaner, we don't need to implement this
processing for every single new object that we introduce into the system,
and your code is able to make decisions on things other than just the
existence of a particular object.

<< I still wonder, why there are really few questions or complaints from the
DBISAMers (there must be a lot of them). >>

Then you will also be very surprised to know that a lot of people are very
happy with EDB as it exists, and are simply learning the new ways of doing
things.  July was the best sales month we've had this entire year, and we
sold a lot of new EDB licenses.  Contrary to the picture you and Roy are
trying to paint here, people actually like the new ways of doing things in
EDB, especially those coming from other products.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

don't be offended - this was neither a complaint, nor a request, just an opinion.

>>Obviously some of you either don't believe me when I give my
>>reasoning, or think that my reasoning isn't valid.  Either way, it doesn't
>>really matter.  IF [NOT] EXISTS is simply never going to show up in EDB.

And that's perfectly OK to me - I had a workaround, it was nothing absolutely necessary. I
only stated some points why I would have decided otherwise - not tried to convince you to
do so. Maybe a support NG is not the best place for that kind of "just talk". Apologies.

>>stop re-hashing these same arguments every week.

You must have a better, and continuing overview about what happens in this NG. I've been
away for a very long time, not needing any support. And in this case, not really vital to
me, I haven't looked up if this argument came up again and again. If I recall correctly, I
mentioned it only twice - and will stop now. Promised

>>We do gain quite a bit from not having IF EXISTS scattered everywhere.

Then the decision to let it out absolutely makes sense to me. You know, I can only make
guesses about what is easy or difficult to implement, what has more or less consequences
to your daily work. This one looked really trivial.

>>Because EDB is a completely different product, and we never stated that DBISAM
compatibility was high.

Again, I was not complaining about that fact. I just wondered, when you must have quite a
few DBISAM customers out there - why. But nevertheless, your decision must have been a
good one, because

>>July was the best sales month we've had this entire year, and we sold a lot of new EDB
licenses.  

Congrats - really great to hear that.

>>Contrary to the picture you and Roy are trying to paint here, people actually like the
new ways of doing things in EDB, especially those coming from other products.

Tim, almost no one mentioning anything can mean different things : almost everybody is
satisfied, or almost no one is using it. Me having trouble that almost no one else has,
could also mean different things : almost everybody is smarter than me, almost everybody
is using EDB in other ways than me, or again, almost no one is using it.

Imagine someone who was used to, in spite of beeing a noob, rarely needing support, and on
the very rare occasions when stumbled over a problem, it was alreay questioned and solved
by others, discussed, or a new build ready - this one is now a daily guest in this NG,
having trouble en masse (again, no offense, you do everything you can), and it looks like
that only one other guy has similar problems.

If you were this someone, what would you think ? I didn't want to paint a picture, it
painted itself. And I'm in fact happy to hear that it is wrong, even if that means I am
too inflexible, old-fashioned or dumb.

Heiko

Heiko,

<< don't be offended - this was neither a complaint, nor a request, just an
opinion. >>

I'm not offended, just a little tired of the same conversation.  I feel like
I've been as clear as I can possibly be regarding DBISAM compatibility with
EDB, and being forced to constantly justify incompatibilities with DBISAM
really wears on me after a while.

<< And that's perfectly OK to me - I had a workaround, it was nothing
absolutely necessary. I only stated some points why I would have decided
otherwise - not tried to convince you to do so. Maybe a support NG is not
the best place for that kind of "just talk". Apologies. >>

No need to apologize.  All I'm asking for is a little benefit of the doubt
as to why things were done the way they were.  My ultimate goals are to make
EDB better than DBISAM, and sometimes that means making things significantly
different than they were with DBISAM.

<< You must have a better, and continuing overview about what happens in
this NG. I've been away for a very long time, not needing any support. And
in this case, not really vital to me, I haven't looked up if this argument
came up again and again. If I recall correctly, I mentioned it only twice -
and will stop now. Promised >>

Sorry, I was probably taking out some frustrations on you there.  My
apologies.

<< Then the decision to let it out absolutely makes sense to me. You know, I
can only make guesses about what is easy or difficult to implement, what has
more or less consequences to your daily work. This one looked really
trivial. >>

It's trivial to implement, but it undercuts the usefulness of the system
tables and causes the developer to constantly look towards us for further
syntax changes to accomodate their needs, instead of using the system tables
for these purposes.  This was one of the biggest mistakes made with DBISAM -
constant expansion of the SQL syntax to accomodate specific metadata
requirements instead of simply providing system tables where *all* of the
metadata can be interrogated.

<< Again, I was not complaining about that fact. I just wondered, when you
must have quite a few DBISAM customers out there - why. But nevertheless,
your decision must have been a good one, because >>

Sure, but there's also a large contingent of DBISAM customers that will
never use EDB for various reasons.  We simply can't spend our time looking
backwards in a constant attempt to lure them to EDB.  If EDB is not
attractive to a DBISAM customer as it currently exists, then it probably is
best for that customer to stick with DBISAM and pay for a support plan.
That's pretty much why we instituted the support plans in the first place.

<< Tim, almost no one mentioning anything can mean different things : almost
everybody is satisfied, or almost no one is using it. Me having trouble that
almost no one else has, could also mean different things : almost everybody
is smarter than me, almost everybody is using EDB in other ways than me, or
again, almost no one is using it. >>

What specifically is causing you so much trouble ?  You have to remember
that EDB has a significantly larger set of functionality than DBISAM, and so
not everyone is going to necessarily use it to the extent that you do, or in
the ways that you do.  You also have to remember that we *started* EDB with
the same test framework that DBISAM acquired over 2 1/2 years through the
version 4.x series.   Therefore, it only makes sense that EDB will have
quite a few less issues than DBISAM had over the same time period, and the
issues that do appear will be in areas of EDB that are new and weren't even
present in DBISAM.

<< Imagine someone who was used to, in spite of beeing a noob, rarely
needing support, and on the very rare occasions when stumbled over a
problem, it was alreay questioned and solved by others, discussed, or a new
build ready - this one is now a daily guest in this NG, having trouble en
masse (again, no offense, you do everything you can), and it looks like that
only one other guy has similar problems. >>

Again, what problems are you experiencing besides the last one reported
regarding a UDF ?

You're comparing the newsgroup of a product that is only a little over 1 1/2
years old to a product that's been around for 10 years.  Have you checked
the volume of the DBISAM newsgroups lately ?  Do you think that the low
volume is because nobody is using DBISAM, or because there aren't any
problems to report ?

<< If you were this someone, what would you think ? I didn't want to paint a
picture, it painted itself. >>

And what picture is that ?

<< And I'm in fact happy to hear that it is wrong, even if that means I am
too inflexible, old-fashioned or dumb.>>

I never said any of those things about you.

--
Tim Young
Elevate Software
www.elevatesoft.com

David

>Really? That surprises me. How is it a violation? Maybe I should revisit
>the NULL definition.

He's saying that null = emptystring would be a standards violation.

>I agree--good points. But Tim can only do so much at once.

Until we get the clone machine working. Mind you I'm always surprised as to how much efficient a single individual is than a team.

>(Now if he's said there are no plans on putting in some of these extensions,
>that would be a different discussion.)

In some respects a list of "these are never going to appear" is better - at least then you know there's no point in waiting round hoping.

>I suppose if the bulk target audience was existing DBISAM users, this would
>be a big question. I suspect he was hoping to expand sales by opening the
>database up to Visual Studio programmers.

A question not even Tim can answer is would it have been financially better for him to include some of these smoothing of the way issues which would have encouraged more people to upgrade.

>Anyway, it's a tough balancing act--there's always going to be people that
>miss or need a feature and those have to be balanced with time and market
>constraints.

And the problem with the 80:20 rule in these cases is is always a different 80% that people want

>Probably like CodeGear deciding what features to put in the
>next version of Delphi...

Yeah - have you been watching the unicode in Tiburon thead?

Roy Lambert

Tim


Sorry - IF EXISTS was simply the first example that came to my mind

Roy Lambert

Tim

>Then you will also be very surprised to know that a lot of people are very
>happy with EDB as it exists, and are simply learning the new ways of doing
>things.

Yeah - but they don't know any better

>July was the best sales month we've had this entire year, and we
>sold a lot of new EDB licenses.

Congratulations.

>Contrary to the picture you and Roy are
>trying to paint here, people actually like the new ways of doing things in
>EDB, especially those coming from other products.

Even I like some (possibly even a lot) of the new stuff, but I also liked things that have been left behind, and some of the new stuff I just don't understand the rational behind.

Roy Lambert