Replication between SQL and Access97?

I have an Access 97 database that I would like to "mirror" in my SQL server 2000 database.

Basically I would like SQL server to keep a current copy of an Access 97 database table which exists on remote machine on our network. Any time there is a change made to the Access table, I would like the SQL server to be updated automatically.

Is this something that is possible to do with replication/synchronization, or do I have to push the data up with another app?

ThanksTo my knowledge you can not set up relication from Access to SQL Server. Are you sure your tables are in Access? Or are you using an Access Data Project or tables linked into a mdb file?

If your tables are truly located locally in your access database the only way I can think of doing what you want to do is to link in your SQL Server tables and for every insert, update and delete you run the same queries against the SQL tables at the same time.

Why not just move your tables in your access application to SQL Server?|||The tables are definately in an Access 97.

I thought about moving the tables into the SQL database but I really need a copy locally in the event of a network failure. (The app which generates the data and fills the tables runs on the machine remote to the SQL database.)

Thanks for your suggestions.|||move the tables to sql. and then you can have DTS packages that push them down to your local access app.

Is'nt your SQL Server running backups on itself anyways?|||Depending on why you want to do this, you could
1)put a copy of sql server on the remote server and then use those tables in your access app. Replication to the other server is then easy if you still want this.
2)use dts packages to copy the data into your sql server tables using a scheduled job.
3)use heterogenous transactional replication but it looks a little complicated at first sight and I know nothing of the implications and practicality of implementing this type of replication|||I clearly need to bone this. I did find some info in the SQL Server Books Online under "Access Subscribers" which looks promising.

I believe this is item 3 refered to in the previous post.

Thanks for your help.sql

Replication Architecture/Design advise

I have been asked to set-up replication in the current two server
enviornment. My understanding is that Log-Shipping requires
the Enterprise version of Sql Server 2000 (Which they do not
have the budget for).
They have 70 Databases that have a total space of aprox 30gb.
They want to replicate the data to the standby server so that
in the case of a failure they can redirect their Web Sites
to the standby Server.
Both servers will be in a co-lo facility so bandwidth between
the servers should be adequate.
Do I do central publisher with the distributor on the standby
server? I am not sure what kind of load this will have. I
understand that people recommend to put it on the publisher
server and only move it if load becomes an issue.
I understand that security (ie, users and permissions) will
not replicate. Other than having to set things up twice is
their other solutions to minimize this?
Sincerely,
Dave
you do not need the Enterprise Edition of SQL Server for log shipping. This
is a mistake in BOL.
Ideally what you want is automatic failover which means hardware or software
data mirroring - however it can be accomplished using log shipping, but you
will have to redirect your clients to the failed over server. You can then
log ship back to the original primary.
If you choose to use replication - I would use bi-directional transactional
replication keeping in mind
1) that every table you are replicating needs a pk
2) system objects and logins are not replicated
3) bi-directional transactional replication is not resilient to schema
changes (i.e. you have to drop your subscriptions and publication when you
want to make schema changes). Other replication types support partial schema
changes using sp_repladdcolumn and sp_repldropcolumn.
For log shipping you will find that
1) its not really scalable - I think you will find the logistical burden log
shipping 70 databases to be a bit overwhelming
2) your standby servers' databases will be read only
For replication you would be using a single publisher and subscriber. It is
a central publisher with one subscriber.
"David Gresham" <gresham@.panix.com> wrote in message
news:d50tct$5je$1@.reader1.panix.com...
>I have been asked to set-up replication in the current two server
> enviornment. My understanding is that Log-Shipping requires
> the Enterprise version of Sql Server 2000 (Which they do not
> have the budget for).
>
> They have 70 Databases that have a total space of aprox 30gb.
> They want to replicate the data to the standby server so that
> in the case of a failure they can redirect their Web Sites
> to the standby Server.
>
> Both servers will be in a co-lo facility so bandwidth between
> the servers should be adequate.
>
> Do I do central publisher with the distributor on the standby
> server? I am not sure what kind of load this will have. I
> understand that people recommend to put it on the publisher
> server and only move it if load becomes an issue.
>
> I understand that security (ie, users and permissions) will
> not replicate. Other than having to set things up twice is
> their other solutions to minimize this?
>
> Sincerely,
>
>
> Dave
>
|||In article <umaTbQdTFHA.2172@.tk2msftngp13.phx.gbl>,
Hilary Cotter <hilary.cotter@.gmail.com> wrote:
>you do not need the Enterprise Edition of SQL Server for log shipping. This
>is a mistake in BOL.
>Ideally what you want is automatic failover which means hardware or software
>data mirroring - however it can be accomplished using log shipping, but you
>will have to redirect your clients to the failed over server. You can then
>log ship back to the original primary.
>If you choose to use replication - I would use bi-directional transactional
>replication keeping in mind
>1) that every table you are replicating needs a pk
>2) system objects and logins are not replicated
>3) bi-directional transactional replication is not resilient to schema
>changes (i.e. you have to drop your subscriptions and publication when you
>want to make schema changes). Other replication types support partial schema
>changes using sp_repladdcolumn and sp_repldropcolumn.
>
Can you expand on what replication model this is? Is this Merge?
Does this mean that the standby server can update the primary?
My situation for this project is that the primary will update
the standby server and will only be used when the primary fails.
My other question is: Lets say we need to rebuild the primary
server. We re-build it and need to bring the databases back
from the standby server. Do we have to start over from scratch?
Or do we need to some-how rebuild everything? I am going to
be ordering your book today. I have worked with replication
before when all we were doing was creating a reporting database
which was read-only.
The standby concept seemed to follow this except for when we
needed to switch over to it. The client hosts several
web sites.
Thanks
Dave

>For log shipping you will find that
>1) its not really scalable - I think you will find the logistical burden log
>shipping 70 databases to be a bit overwhelming
>2) your standby servers' databases will be read only
>For replication you would be using a single publisher and subscriber. It is
>a central publisher with one subscriber.
>"David Gresham" <gresham@.panix.com> wrote in message
>news:d50tct$5je$1@.reader1.panix.com...
>
|||This is transactional, bi-directional transactional replication to be
specific, not to be confused with transactional replication with immediate
updating, transactional replication with queued updating, transactional
replication with immediate updating with queued failover, or merge
replication. However merge replication might work for you, although it will
add a guid column to each column you are replicating.
It does mean that your standby could update the primary, and it is an
excellent choice when the primary goes offline and all database activity
occurs on the standby server then.
Ideally you would use bi-directional replication in a case where your
publisher goes offline for an extended time period. When it comes back
online you should backup the standby by restore it on the publisher,
recreate the publications and subscriptions on the publisher and then do a
no sync,
Review this link for more info on these options.
http://support.microsoft.com/default...b;en-us;820675
"David Gresham" <gresham@.panix.com> wrote in message
news:d52qja$4j4$1@.reader1.panix.com...
> In article <umaTbQdTFHA.2172@.tk2msftngp13.phx.gbl>,
> Hilary Cotter <hilary.cotter@.gmail.com> wrote:
> Can you expand on what replication model this is? Is this Merge?
> Does this mean that the standby server can update the primary?
> My situation for this project is that the primary will update
> the standby server and will only be used when the primary fails.
> My other question is: Lets say we need to rebuild the primary
> server. We re-build it and need to bring the databases back
> from the standby server. Do we have to start over from scratch?
> Or do we need to some-how rebuild everything? I am going to
> be ordering your book today. I have worked with replication
> before when all we were doing was creating a reporting database
> which was read-only.
> The standby concept seemed to follow this except for when we
> needed to switch over to it. The client hosts several
> web sites.
> Thanks
>
> Dave
>
>
|||In article <eOqh7CmTFHA.544@.TK2MSFTNGP15.phx.gbl>,
Hilary Cotter <hilary.cotter@.gmail.com> wrote:
>This is transactional, bi-directional transactional replication to be
>specific, not to be confused with transactional replication with immediate
>updating, transactional replication with queued updating, transactional
>replication with immediate updating with queued failover, or merge
>replication. However merge replication might work for you, although it will
>add a guid column to each column you are replicating.
>It does mean that your standby could update the primary, and it is an
>excellent choice when the primary goes offline and all database activity
>occurs on the standby server then.
>Ideally you would use bi-directional replication in a case where your
>publisher goes offline for an extended time period. When it comes back
>online you should backup the standby by restore it on the publisher,
>recreate the publications and subscriptions on the publisher and then do a
>no sync,
>Review this link for more info on these options.
>http://support.microsoft.com/default...b;en-us;820675
>
In reading this document I got a 'little' intimidated by the need
for all these custom stored procedures. Since the server will
only be used in such a way that there would never be any
conflicts do I need to worry about this?
I also wanted to clarify where the distributor is in this set-up,
the Subscriber?
Thanks
Dave
sql

Replication - Publisher moving to a different server

Hi,
I need to move my publisher to a different database as the current server on
which it is running is slow compared to my current requirements.
But I have 2 subscribers to this server. I have merge replication in SQL
Server 2k with sp3 on.
Can someone advice me as to how to have a smooth transition? I cannot just
replace the harddisk as the new server has a much powerful harddisk.
Is it possible for me to just restore the backup of the current publisher on
the new server alongwith the master and msdb, and replication starts? I will
take care to name the new server as the old one and remove the old one from
the network.
Can someone please help me with the same?
Thank you in advance.
Regards,
Karthik
The best approach is to drop the publication move the database to a new
server and then configure this server as the publisher and publish the
database to the subscriber.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Karthik" <Karthik@.discussions.microsoft.com> wrote in message
news:6AE54F19-FB6F-4DDA-85DC-9430C4C8BF70@.microsoft.com...
> Hi,
> I need to move my publisher to a different database as the current server
on
> which it is running is slow compared to my current requirements.
> But I have 2 subscribers to this server. I have merge replication in SQL
> Server 2k with sp3 on.
> Can someone advice me as to how to have a smooth transition? I cannot just
> replace the harddisk as the new server has a much powerful harddisk.
> Is it possible for me to just restore the backup of the current publisher
on
> the new server alongwith the master and msdb, and replication starts? I
will
> take care to name the new server as the old one and remove the old one
from
> the network.
> Can someone please help me with the same?
> Thank you in advance.
> Regards,
> Karthik
>
|||Hi Hilary,
Thank you for the advice.
But the problem is, one of my subscriber is a remote subscriber. And this
subscriber is in a different continent. If I try to drop and recreate the
subscription, it fails to apply the initial snapshot as the shapshot is more
than 2 GB. Is there any other way I can go about applying the snapshot in
case I really need to drop the publication and go about this situation?
Thank you once again.
Regards,
Karthik.
"Hilary Cotter" wrote:

> The best approach is to drop the publication move the database to a new
> server and then configure this server as the publisher and publish the
> database to the subscriber.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "Karthik" <Karthik@.discussions.microsoft.com> wrote in message
> news:6AE54F19-FB6F-4DDA-85DC-9430C4C8BF70@.microsoft.com...
> on
> on
> will
> from
>
>
|||Karthik,
you could do a nosync initialization of this particular
subscriber. The table could be transferred using the
normal means - linked servers, DTS, BCP (with winzip),
backup and restore - or it may be that the subscriber and
publisher are already in sync, in which case you won't
need to do the transfer. To verify if this is the case,
you can do a binary checksum test.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul,
The publisher and subscriber would not have too many changes as I would be
moving the servers over the weekend. I can safely assume that no user would
be connected at either the publisher or subscriber over the weekend.
So do you think I can just restore the backup's of the master, msdb,
distribution, alongwith the replicated database on to the new server?
Also what is binary checksum test?
Thank you in advance.
Karthik.
"Paul Ibison" wrote:

> Karthik,
> you could do a nosync initialization of this particular
> subscriber. The table could be transferred using the
> normal means - linked servers, DTS, BCP (with winzip),
> backup and restore - or it may be that the subscriber and
> publisher are already in sync, in which case you won't
> need to do the transfer. To verify if this is the case,
> you can do a binary checksum test.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Karthik,
you just need to run the merge agent then prevent any changes on the
publisher and subscriber. Remove the subscription. Restore the subscriber's
database on the new server. Create a new subscription and in the wizard
state that there is no need to synchronize the data.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul,
Thank you for the information.
But I have a query, why should I restore the subscriber if I am not touching
the subscriber at all?
The only thing I need to do is to move the publisher to a different machine
(with different configuration but the same name).
I am not an expert at replication, so I may not understand what you are
trying to telling me. I am sorry if that is the case. But it would be really
helpful if you could explain to me in slightly greater detail.
Thank you in advance.
Regards,
Karthik
"Paul Ibison" wrote:

> Karthik,
> you just need to run the merge agent then prevent any changes on the
> publisher and subscriber. Remove the subscription. Restore the subscriber's
> database on the new server. Create a new subscription and in the wizard
> state that there is no need to synchronize the data.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Karthik,
my apologies. I hadn't noticed that my Outlook Express doesn't have your
first post so I was replying to the thread from your reply onwards.
Backing up the publisher database, master, msdb and distribution database
and restoring them on the new (identical named) server will allow everythng
to continue as before. If this is not possible, backing up the publishing
database and restoring it on a new server, setting up the merge replication
from scratch and when adding the subscriber selecting the option to not
initialize the data is another option. This is referred to as a nosync
initialization. For this to work, the subscriber and publisher databases
need to be identical, so after synchronizing before the database move, you
must ensure no other data changes can occur.
Regards,
Paul Ibison
|||Hi Paul,
Thank you once again.
One last thing that I wanted to ask was about the snapshot directory. In my
earlier setup, the snapshot directory (FTP) was in the same machine that
contained the publisher database.
So if I create the snapshot folder in the same path in my new publisher
would things be in place?
Thank you in advance.
Regards,
Karthik
"Paul Ibison" wrote:

> Karthik,
> my apologies. I hadn't noticed that my Outlook Express doesn't have your
> first post so I was replying to the thread from your reply onwards.
> Backing up the publisher database, master, msdb and distribution database
> and restoring them on the new (identical named) server will allow everythng
> to continue as before. If this is not possible, backing up the publishing
> database and restoring it on a new server, setting up the merge replication
> from scratch and when adding the subscriber selecting the option to not
> initialize the data is another option. This is referred to as a nosync
> initialization. For this to work, the subscriber and publisher databases
> need to be identical, so after synchronizing before the database move, you
> must ensure no other data changes can occur.
> Regards,
> Paul Ibison
>
>
|||Karthik,
if you chnage the directory used, the ftp properties will need altering but
this only applies to initialization, so it won't make any difference in your
case if you're restoring all databases to an identically-named server. If
you're restoring to a new server and doing a no-sync initialization (merge)
then the ftp path, login etc will need changing because even though the data
isn't transferred, the metadata is created on the subscriber.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

replication - need input

Hello everyone,
I am planning to replace one of our database servers (SERVERPUB) with a
brand new one. The current server has few databases that are being replicated
(publishers) to another subscriber server (SERVERSUB) going through a
dedicated distributor server(SERVERDIS). All replications are transactional.
Also one of the databases on SERVERPUB is a subscriber. So to make a long
story short, SERVERPUB has databases being published and also hold a database
which is a subscriber.
My question is what is the best way to recreate the replication on SERVERPUB?
At this stage I am planning to do the following:
1. Generate all replication scripts for each database on the publisher
(delete and creation scripts)
2. Run the delete replication script to remove replication on SERVERPUB
3. Do all the work to rebuild the new server and have all databases, logins
and everything ready
4. Run the script to recreate all publications
With this solution I expect the following problem: when I'll start the
snapshot, the destination tables on the subscribers get dropped and recreated
and I lose thepermissions on those tables as the permission on the
subscribers are slightly different (report users) from the publisher. I need
to reapply all permissions.
Is there a better way of doing this?
--
Sasan Saidi
Senior DBA
When you create the article for the publication, you can specify the
destination tables to be dropped then recreated, or just delete all records
in the table. If you are using T-SQL to do this, look for sp_addarticle in
BOL. If you are using EM. Right-click on the
publication>properties>Articles Tab>click on the "..." button next to the
object>Snapshot Tab. You will see there are several choices you can select
under "name conflicts". I prefer T-SQL because you can use "truncate", which
is faster then delete all records and that option is not avaiable on GUI.
"Sasan Saidi" wrote:

> Hello everyone,
> I am planning to replace one of our database servers (SERVERPUB) with a
> brand new one. The current server has few databases that are being replicated
> (publishers) to another subscriber server (SERVERSUB) going through a
> dedicated distributor server(SERVERDIS). All replications are transactional.
> Also one of the databases on SERVERPUB is a subscriber. So to make a long
> story short, SERVERPUB has databases being published and also hold a database
> which is a subscriber.
> My question is what is the best way to recreate the replication on SERVERPUB?
> At this stage I am planning to do the following:
> 1. Generate all replication scripts for each database on the publisher
> (delete and creation scripts)
> 2. Run the delete replication script to remove replication on SERVERPUB
> 3. Do all the work to rebuild the new server and have all databases, logins
> and everything ready
> 4. Run the script to recreate all publications
> With this solution I expect the following problem: when I'll start the
> snapshot, the destination tables on the subscribers get dropped and recreated
> and I lose thepermissions on those tables as the permission on the
> subscribers are slightly different (report users) from the publisher. I need
> to reapply all permissions.
> Is there a better way of doing this?
>
> --
> --
> Sasan Saidi
> Senior DBA
>

replication - need input

Hello everyone,
I am planning to replace one of our database servers (SERVERPUB) with a
brand new one. The current server has few databases that are being replicate
d
(publishers) to another subscriber server (SERVERSUB) going through a
dedicated distributor server(SERVERDIS). All replications are transactional.
Also one of the databases on SERVERPUB is a subscriber. So to make a long
story short, SERVERPUB has databases being published and also hold a databas
e
which is a subscriber.
My question is what is the best way to recreate the replication on SERVERPUB
?
At this stage I am planning to do the following:
1. Generate all replication scripts for each database on the publisher
(delete and creation scripts)
2. Run the delete replication script to remove replication on SERVERPUB
3. Do all the work to rebuild the new server and have all databases, logins
and everything ready
4. Run the script to recreate all publications
With this solution I expect the following problem: when I'll start the
snapshot, the destination tables on the subscribers get dropped and recreate
d
and I lose thepermissions on those tables as the permission on the
subscribers are slightly different (report users) from the publisher. I need
to reapply all permissions.
Is there a better way of doing this?
--
Sasan Saidi
Senior DBAWhen you create the article for the publication, you can specify the
destination tables to be dropped then recreated, or just delete all records
in the table. If you are using T-SQL to do this, look for sp_addarticle in
BOL. If you are using EM. Right-click on the
publication>properties>Articles Tab>click on the "..." button next to the
object>Snapshot Tab. You will see there are several choices you can select
under "name conflicts". I prefer T-SQL because you can use "truncate", whic
h
is faster then delete all records and that option is not avaiable on GUI.
"Sasan Saidi" wrote:

> Hello everyone,
> I am planning to replace one of our database servers (SERVERPUB) with a
> brand new one. The current server has few databases that are being replica
ted
> (publishers) to another subscriber server (SERVERSUB) going through a
> dedicated distributor server(SERVERDIS). All replications are transactiona
l.
> Also one of the databases on SERVERPUB is a subscriber. So to make a long
> story short, SERVERPUB has databases being published and also hold a datab
ase
> which is a subscriber.
> My question is what is the best way to recreate the replication on SERVERP
UB?
> At this stage I am planning to do the following:
> 1. Generate all replication scripts for each database on the publisher
> (delete and creation scripts)
> 2. Run the delete replication script to remove replication on SERVERPUB
> 3. Do all the work to rebuild the new server and have all databases, login
s
> and everything ready
> 4. Run the script to recreate all publications
> With this solution I expect the following problem: when I'll start the
> snapshot, the destination tables on the subscribers get dropped and recrea
ted
> and I lose thepermissions on those tables as the permission on the
> subscribers are slightly different (report users) from the publisher. I ne
ed
> to reapply all permissions.
> Is there a better way of doing this?
>
> --
> --
> Sasan Saidi
> Senior DBA
>

replication - need input

Hello everyone,
I am planning to replace one of our database servers (SERVERPUB) with a
brand new one. The current server has few databases that are being replicated
(publishers) to another subscriber server (SERVERSUB) going through a
dedicated distributor server(SERVERDIS). All replications are transactional.
Also one of the databases on SERVERPUB is a subscriber. So to make a long
story short, SERVERPUB has databases being published and also hold a database
which is a subscriber.
My question is what is the best way to recreate the replication on SERVERPUB?
At this stage I am planning to do the following:
1. Generate all replication scripts for each database on the publisher
(delete and creation scripts)
2. Run the delete replication script to remove replication on SERVERPUB
3. Do all the work to rebuild the new server and have all databases, logins
and everything ready
4. Run the script to recreate all publications
With this solution I expect the following problem: when I'll start the
snapshot, the destination tables on the subscribers get dropped and recreated
and I lose thepermissions on those tables as the permission on the
subscribers are slightly different (report users) from the publisher. I need
to reapply all permissions.
Is there a better way of doing this?
--
--
Sasan Saidi
Senior DBAWhen you create the article for the publication, you can specify the
destination tables to be dropped then recreated, or just delete all records
in the table. If you are using T-SQL to do this, look for sp_addarticle in
BOL. If you are using EM. Right-click on the
publication>properties>Articles Tab>click on the "..." button next to the
object>Snapshot Tab. You will see there are several choices you can select
under "name conflicts". I prefer T-SQL because you can use "truncate", which
is faster then delete all records and that option is not avaiable on GUI.
"Sasan Saidi" wrote:
> Hello everyone,
> I am planning to replace one of our database servers (SERVERPUB) with a
> brand new one. The current server has few databases that are being replicated
> (publishers) to another subscriber server (SERVERSUB) going through a
> dedicated distributor server(SERVERDIS). All replications are transactional.
> Also one of the databases on SERVERPUB is a subscriber. So to make a long
> story short, SERVERPUB has databases being published and also hold a database
> which is a subscriber.
> My question is what is the best way to recreate the replication on SERVERPUB?
> At this stage I am planning to do the following:
> 1. Generate all replication scripts for each database on the publisher
> (delete and creation scripts)
> 2. Run the delete replication script to remove replication on SERVERPUB
> 3. Do all the work to rebuild the new server and have all databases, logins
> and everything ready
> 4. Run the script to recreate all publications
> With this solution I expect the following problem: when I'll start the
> snapshot, the destination tables on the subscribers get dropped and recreated
> and I lose thepermissions on those tables as the permission on the
> subscribers are slightly different (report users) from the publisher. I need
> to reapply all permissions.
> Is there a better way of doing this?
>
> --
> --
> Sasan Saidi
> Senior DBA
>

Replication - Identity Value problem

Hi,
I have a table with a tinyint (identity column). The current value in the
table is 2. And if I check with IDENT_CURRENT the next value is displayed as
3.
This table is an article in a merge replication. In EM if I check this
article the next value is shown as 127. And this is leading to problems in
replication. How can I get the 127 to something more manageable (say 3)?
Thank you.
Regards,
Karthik
You would be best not messing with this. However use DBCC
CheckIdent('tablename',reseed,3)
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Karthik" <Karthik@.discussions.microsoft.com> wrote in message
news:ABEDD870-6C5F-473C-9B15-74594B434C29@.microsoft.com...
> Hi,
> I have a table with a tinyint (identity column). The current value in the
> table is 2. And if I check with IDENT_CURRENT the next value is displayed
as
> 3.
> This table is an article in a merge replication. In EM if I check this
> article the next value is shown as 127. And this is leading to problems in
> replication. How can I get the 127 to something more manageable (say 3)?
> Thank you.
> Regards,
> Karthik
|||Hilary Cotter wrote:
> You would be best not messing with this. However use DBCC
> CheckIdent('tablename',reseed,3)
>
I've noticed the same thing -- on an INT identity, the value suddenly
(after 3 inserts) jumps to about 1.5 billion -- 1/2 way through the
range, it seems. Is this a bug, or a "feature"?