Leslie,

<< Any chance that queries with joins will result sensitive resultsets? >>

Yes, it's on the list for being addressed at some point.  EDB is close, but
not quite there, in terms of sensitive result sets for joins.

<< If yes, does this mean that optimisation will use indexes for such
queries? >>

I really can't say for sure at this point.  It's certainly a lot more
difficult than a single-table situation, so there's probably some serious
issues to be addressed.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

I can see that you have a lot of enhancements to think about, but I think there is
probably a less difficult way to "emulate" an updateable view.  Actually it would provide
something, which in many cases is more useful then a view, and could be more easily
optimized in joins for the compiler and for the users as well.
  
The result set of a query on a disk dataset can be selected into a memory table. If I got
it right, at the moment it can only be done by recreating the in memory dataset. Would it
be difficult to extend this functionality to allow to target an existing table?  

With a BatchMove alike SQL command with a few options to refine the update process we
could have an incremental synchronization into one direction. In the simplest case after
posting changes to a record this would allow to refresh the fields which are not from the
base table. With an added RefreshRecordSQL property  to an UpdateSQL alike object the user
could control how refreshing is done.


To the other direction the UpdateSQL object could store all the updates to the source DB
or wherever the user wants to.

All together an inmemory table/query/view which can be updated incrementally from any
other table and can apply changes to the source (probably disk) database would be ideal
for client side programs. It would provide the functionality of a cached dataset as well.
I guess the code made for replication already contains most of the logic required here.

Most of these I would be able to code myself, I just cannot adapt it to the code of
ElevateDB, and do not have much time for it right now. I should be getting to work on the
business logic part of the applications very fast, but I really would  like to change to
ElvateDB so am still trying to find the ways to implement what we need on the data
handling level with it.

The second main problematic area is this: We need to build thick clients with lots of data
stored and queried locally, store changes locally in a disk database and apply them to a
remote server when online. Replication would do the business, but as I understand there is
no way to control on the publishers side what changes are published for different kind of
clients. I could try to delete the unintended data after applying it to the client
database, but it is risky to send all business sensitive data to all clients outside the
company. They should be getting only what they are paying for.

Leslie

Leslie,

<< I can see that you have a lot of enhancements to think about, but I think
there is probably a less difficult way to "emulate" an updateable view.
Actually it would provide something, which in many cases is more useful then
a view, and could be more easily optimized in joins for the compiler and for
the users as well. >>

What is in our plans is for an "INSTEAD OF" trigger that can be defined for
any view that will allow you to take an insert, update, and delete, and
propogate it to the source table(s) as required.  That way you can code how
the update should take place, and it will be present in the database.  This
is the best option for us because it doesn't involve any Delphi-specific
code or constructs, and will port easily to .NET, FP, etc.

<< The second main problematic area is this: We need to build thick clients
with lots of data stored and queried locally, store changes locally in a
disk database and apply them to a remote server when online. Replication
would do the business, but as I understand there is no way to control on the
publishers side what changes are published for different kind of clients. I
could try to delete the unintended data after applying it to the client
database, but it is risky to send all business sensitive data to all clients
outside the company. They should be getting only what they are paying for.
>>

This is something that we already have planned - filter criteria for the
SAVE UPDATES statement so that you can specify which updates are added to
the update file.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

"This is the best option for us because it doesn't involve any Delphi-specific
code or constructs, and will port easily to .NET, FP, etc."

Clear.

Looks like I will have to implement the replication anyway and it could cover the
functionality I have mentioned here. I will narrow my question:  

-   Selecting to an existing target table.
-   Performing UPDATE_OR_INSERT while updating the target table

Are these difficult to implement for you?
Is this something you would want to do?
If yes, how does it fit in to your plans?  

Thanks,
Leslie

Leslie,

<< - Selecting to an existing target table. >>

Do you mean something like INSERT INTO....SELECT * FROM ?

<< - Performing UPDATE_OR_INSERT while updating the target table >>

This is on our enhancements list, but I don't have a timeframe for it at
this time.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Looks like I will have to implement the replication anyway..."

Unless you can implement these:

- Performing character encoding conversion while applying the replicated changes. (Without
this the WinCE client is useless for us, because all the other client and server apps has
to be none unicode.)  
- Filtered replication.
- Multiply replication with different filter settings.

(I thought these had no chance within our time limit, that is whay I did not ask first. )

Leslie

Tim,

"Do you mean something like INSERT INTO....SELECT * FROM ?"

Exactly. Of course this is something what can easily be done the user, but usually there
is a great difference in speed if it is done internally by the engine. This is the reason
why I have brought it up.


"<< - Performing UPDATE_OR_INSERT while updating the target table >>

This is on our enhancements list, but I don't have a timeframe for it at
this time."

This one seems to require only a few lines of code ... (I understand that there are
more things you consider than I can think of when deciding what should come first. Please
do not feel pushed by my many "I wish" questions. I have got to ask these questions in
order to be able to make my decisions.)  

Leslie   

"Do you mean something like INSERT INTO....SELECT * FROM ?"


or UPDATE OR INSERT INTO....SELECT * FROM   

Leslie   

Leslie,

<< Exactly. Of course this is something what can easily be done the user,
but usually there is a great difference in speed if it is done internally by
the engine. This is the reason why I have brought it up. >>

I'm not sure what you mean - INSERT INTO..SELECT *is* done internally by the
engine.

<< This one seems to require only a few lines of code ... >>

Sure, if you don't have any documentation and testing to worry about.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< - Performing character encoding conversion while applying the replicated
changes. (Without this the WinCE client is useless for us, because all the
other client and server apps has to be none unicode.) >>

Why do the other client and server applications have to use the non-Unicode
version of EDB ?  There's no difference in terms of performance, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com