Tim:

>>I will look into this further and make a decision for build 2.    The
round-trip times on C/S may be insignificant enough that it doesn't matter.<<

How about making this a property setting for the Table, Query, and Stored Procedure components.  AllowDefaults for example.  When set to true, it mimics and behaves
like DBisam 4.x and when set to false it behaves as it does now.  It gives the developer greater control and allows him to optimize each dataset as necessary to strike a
balance between performance and functionality.  The developer can decide for themselves if the extra trip to the server is worthwhile or not.  

Implementing a property setting like this keeps ElevateDB flexible and does not lock it into one scheme or the other.  It takes you out of the loop and leaves it up to the
developer to decide.

Tom

Tom,

<< Implementing a property setting like this keeps ElevateDB flexible and
does not lock it into one scheme or the other.  It takes you out of the loop
and leaves it up to the developer to decide. >>

Yes, but I just spent a lot of time trimming down properties like this for
EDB compared to what DBISAM had, and I'm rather hesitant about starting to
pump the number back up.  In most cases it is better to simply have one way
of dealing with things because it keeps support costs and the confusion
factor down.  For every "flexibility" property that we add to the product,
we can expect hundreds and hundreds of questions regarding its usage, and in
most cases the user simply sticks with the default anyways.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

<<Yes, but I just spent a lot of time trimming down properties like this for
EDB compared to what DBISAM had, and I'm rather hesitant about starting to
pump the number back up.  In most cases it is better to simply have one way
of dealing with things because it keeps support costs and the confusion
factor down.  For every "flexibility" property that we add to the product,
we can expect hundreds and hundreds of questions regarding its usage, and in
most cases the user simply sticks with the default anyways.>>


Point well taken.  Some of the subtleties and nuances brought with flexibility are
lost on many users which can cause allot of confusion and certainly higher tech
support costs.  I trust you will make the right decision for ElevateDB.

Tom

Tim

<<Frankly, I simply missed it in the migration guide.  I knew that there would
be a few things like this that I missed since they are so subtle.  Either
way, I will update the migration guide accordingly after I make a decision
on what to do.>>


Did you decide what you are going to do with the DBIsam vs ElevateDB default values issue.  I checked the "New Incident Reports for Version 1.01 Final" and the
migration guide and I did not see it there.  Thanks

Tom

Tom,

<< Did you decide what you are going to do with the DBIsam vs ElevateDB
default values issue.  I checked the "New Incident Reports for Version 1.01
Final" and the migration guide and I did not see it there.  Thanks >>

Shoot, I'm sorry.  No, I forgot all about it.  I will definitely put it in
the pile to be looked at for the next minor revision.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

<<Shoot, I'm sorry.  No, I forgot all about it.  I will definitely put it in
the pile to be looked at for the next minor revision.>>

For now I will assume it won't be in the next minor version and plan accordingly.  If you are able to make it work like DBIsam in the next release then it will be a pleasant suprise.

Thanks for your work on this.  It's greatly apprciated.

Tom