"Knight, Doug" <dknight at wsi.com> writes:
>       :o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
>
> 								     All,:p>
>
> We use time partitioned tables quite extensively (day boundaries). I've looked at the documentation concerning support for partitioned tables, and
>   understand the process steps (EXECUTE SCRIPT, CREATE SET, SET ADD TABLE, SUBSCRIBE SET, SYNC, WAIT FOR EVENT, MERGE SET). I have two questions
>    about this process: 1) What set ID do I use in the EXECUTE SCRIPT command, the target set to which I'm merging or the new temporary set I'm
> 	       creating for the merge?; 2) Does the temporary set ID go away (i.e. can be resued) after executing the MERGE SET?:p>


1.  Which set you use for EXECUTE SCRIPT isn't very important; it used
to be used to indicate which set's tables would be "unlocked from
replication," but that proved error-prone, so *all* tables get taken
out of replication mode during EXECUTE SCRIPT.

2.  Yes, the temporary set ID does indeed go away after running MERGE
SET.

>  Also, is there an easy way to determine what would be the next
>  unique table ID, assuming all of my table IDs are allocated
>  sequentially starting > at 1? The goal of these questions is to
>  support an automated process to handle the daily addition of time
>  partitioned tables.:p>

The best I can think of is to run a query that finds max(tab_id) from
sl_table, and add 1 to that.  There is no sequence used for the table
ID, so there isn't anything built-in that would specifically help with
this.
-- 
output = ("cbbrowne" "@" "linuxdatabases.info")
http://cbbrowne.com/info/
"In order to make an apple pie from scratch, you must first create the
universe."  -- Carl Sagan, Cosmos