Sorin,

<< Will the CachedUpdates issue included on this version? >>

Yes, the cached updates will be part of the replication functionality.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dan,

<< It's my birthday today, so the v1.08 release will do fine.... >>

Happy Birthday !

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim
>
> It will basically allow any remote session to subscribe to an ElevateDB
> Server database (or subset of tables in a database) that has first been
> published by the ElevateDB Server, and then synchronize with that same
> ElevateDB Server at an interval determined solely by the remote session.
>
Sound interesting, couple of questions, maybe too early to answer.

1) Will one ElevateDB Server be able to subscribe to another in a master/slave configuration?
2) Will this mean the slave server database, is in effect, read only?
3) Will two way replication be supported, where the servers subscribe to each other?

Thanks Stu

Stuart,

<< 1) Will one ElevateDB Server be able to subscribe to another in a
master/slave configuration? >>

At this point, yes, although if there's something that is going to bite me
in the rear, this is probably that feature.

<< 2) Will this mean the slave server database, is in effect, read only? >>

No.

<< 3) Will two way replication be supported, where the servers subscribe to
each other? >>

There really is no need - once one end synchronizes with the other, then it
is synchronized as far as both ends are concerned.  Unless you're talking
about synchronizing different databases/tables on each end ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Looking forward to it.  Let us know when you are taking preorders so I can
donate to the cause.

Lance


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:9BF16794-0CBD-4AFF-8EEB-205803FB6095@news.elevatesoft.com...
>I expect ElevateDB 2.0 to be ready by the end of March, and will, as of
>now, include the following features and improvements.   Please note that
>this list is subject to possible change.
>
> .NET and Visual Studio
> ----------------------
>
> - Better Visual Studio design-time integration, including DDL operations
> such as altering tables, procedures, executing scripts, etc.
>
> Functionality
> -------------
>
> - Replication for the ElevateDB Server using a publish/subscribe model
>
> - Messaging layer for general messaging notifications and broadcasts with
> the ElevateDB Server
>
> - Procedures and functions at the session level for use with all databases
>
> - Integrated procedure, function, and script debugging
>
> - Query optimizer has ability to optimize conditions using multi-column
> indexes
>
> - Customizable transaction timeouts for specifying how long a transaction
> waits for the applicable locks
>
> - Defaulting configuration paths to blank ("") and issuing an error if the
> configuration path is blank, along with design-time editor for selection
>
> - INCLUDING CONSTRAINTS, INDEXES, and TRIGGERS clauses for CREATE
> TABLE..AS statement
>
> - TABLES clause will be optional for BACKUP DATABASE and RESTORE DATABASE
> statements
>
> - Option to exclude specific sessions from the ElevateDB Server license
> count
>
> - Ability to retrieve execution plans for EXECUTE and EXECUTE IMMEDIATE
> statements
>
> - Script parameters are populated after the SQL is specified, without
> requiring a prepare operation first
>
> - ROW and ARRAY types
>
> - Error messages for ambiguous column references in joined SELECT
> statements
>
> - Ability to specify the precision for the values returned by the
> CURRENT_DATE, CURRENT_TIME, or CURRENT_TIMESTAMP functions
>
> - Ability to rename database objects
>
> - Ability to copy database objects
>
> - Ability to specify the buffering settings for query result sets
>
> - Ability to lock databases exclusively and have all database DDL
> operations buffered until database is closed
>
> - Option to log any error messages during an IMPORT TABLE instead of
> raising an exception immediately
>
> - Allow parameters for CREATE TABLE AS statements
>
> - Option for specifying that query result sets less than a certain size
> should be buffered in memory completely and not generate a temporary table
>
> - Ability to mark tables, views, and procedures as read-only at the
> catalog level
>
> - Ability to log custom information, warning, or error events into the
> ElevateDB log manager
>
> - New LIST aggregate function for concatenating values within a group or
> for the entire query
>
> - Ability to generate sensitive results sets for SELECT statements with
> sub-queries in the SELECT column list
>
> - SET PROGRESS, SET STATUS MESSAGE, and SET LOG MESSAGE SQL/PSM statements
> for scripts, procedures, etc. along with an ABORT statement and ABORTED
> function for allowing end users to abort scripts, procedures, etc. during
> progress updates
>
>
> ElevateDB Manager
> -----------------
>
> - Individual object reverse-engineering
>
> - Ability to save and restore the current session view
>
> - Improved key handling in the SQL editor for word selection, etc.
>
> - Selectable sorts for database objects, creation order or alphabetical by
> object name
>
> - Unprepare option for statements and scripts
>
> - Templates for SQL statements and scripts
>
> Further Enhancements
> --------------------
>
> In addition to the above-mentioned items, there will also be quite a few
> smaller improvements included that are directly from user enhancement
> requests, but are just a bit too specifc to detail here.  A lot of these
> items concern minor cosmetic issues with the ElevateDB Manager, for
> example.
>
> Cost
> ----
>
> The ElevateDB 2.0 upgrade for ElevateDB 1.0 customers will cost $99 for
> STD and STD-SRC products, and $129 for CS and CS-SRC products.  The
> upgrade period will be 90 days, after which the upgrade pricing for 1.0
> will revert to a simple 10% discount for existing ElevateDB 1.0 customers.
> We will also be issuing bug fixes and updates for ElevateDB 1.0 up until
> the end of the 90-day period, after which the ElevateDB 1.0 code base will
> be frozen.  This is, of course, provided that ElevateDB 1.0 is stable
> enough to warrant suspending bug fixes, which we feel will be possible by
> that time. There will be no format changes or any technical effort
> required to move to ElevateDB 2.0 from 1.0, apart from a simple
> re-compile.
>
> Moving Forward
> --------------
>
> In general, we will be issuing a major upgrade to ElevateDB every year
> around this time (the anniversary of the first ElevateDB release), and the
> terms of the upgrade will be very similar each year.  However, there will
> be an exception when we introduce the ElevateDB Enterprise Server later
> this year.  Check in to the newsgroups or the web site on a regular basis
> to find out more information as it becomes available.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Hi Tim,

Thanks for answering my questions, looking forward to the release.

>
>> 3) Will two way replication be supported, where the servers subscribe to each other?
>
> There really is no need - once one end synchronizes with the other, then it
> is synchronized as far as both ends are concerned.  Unless you're talking
> about synchronizing different databases/tables on each end ?
>
Example, I have a SLAES table,  on the master server and slave server database.  
If I add a record to the slave SALES table, will this get copied to the master server
database during the synchronisation?

I'll guess I've need a unique primary key value, for this to work.


Thanks Stu

Stuart,

<< Example, I have a SLAES table,  on the master server and slave server
database.  If I add a record to the slave SALES table, will this get copied
to the master server database during the synchronisation? >>

Yes, synchronization is a two-way street.

<< I'll guess I've need a unique primary key value, for this to work. >>

No, EDB can just use the unique internal row ID if you don't have an
explicit primary key defined for a table.

--
Tim Young
Elevate Software
www.elevatesoft.com

> - Messaging layer for general messaging notifications and broadcasts with
> the ElevateDB Server
>
> - Procedures and functions at the session level for use with all databases

Will this allow me to write Delphi server procedures that will run in
the server process?  I'm still hanging out for some kind of equivalent
to DBISAM's server procedures, since my whole application is written
around DBSIAM as middleware

Hopefully these notifications and broadcasts will let my server code
notify clients of server events.


  Oliver

Oliver,

<< Will this allow me to write Delphi server procedures that will run in the
server process? >>

They've always run in the server process.  This will give you something
close to the DBISAM procedures, minus direct access to a TDBISAMSession and
any relationship to the parent session.

<< Hopefully these notifications and broadcasts will let my server code
notify clients of server events. >>

That's exactly what they will do, among other things.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Oliver,
>
> << Will this allow me to write Delphi server procedures that will run in the
> server process? >>
>
> They've always run in the server process.  This will give you something
> close to the DBISAM procedures, minus direct access to a TDBISAMSession and
> any relationship to the parent session.

OK, so the server thread would have to create its own session and
presumably could not share temporary tables with its invoking thread,
but could create its own memory tables and work with disk tables.  No
problem.

> << Hopefully these notifications and broadcasts will let my server code
> notify clients of server events. >>
>
> That's exactly what they will do, among other things.

Fantastic!  My current approach of leaving a thread sitting waiting on a
blocked server procedure call has some disadvantages.


  Oliver