Changeseed function

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have the Changeseed function suggested by Microsoft
http://support.microsoft.com/default.aspx?scid=kb;en-us;q287756
It was working fine until I replicated my database. Now, the function stops
and I get this error: Run-time error '-2147217887 (80040e21)' "Multiple-step
OLE DB operation generated errors. Check each OLE DB status value, if
available. No work was done." When I debug it highlights the code line
col.Properties("Seed") = lngSeed
the left side value shows what the current seed is, and the right side value
shows the new seed value that I pass through a form button...ChangeSeed ("tbl
jvsheet","jrnl_line_nbr",1)...my table and column...You can easily see what
is going on if you follow the link and look at the code

Anyway, it doesn't work now. I copy the code to a new module in a new
database, make a simple table, and it works perfectly. What explanation or
solution is there to my problem? Why doesn't it work in my replicated "design
master", or "replica" databases?
 
This function would not serve any useful purpose in a replicated MDB,
because when you replicate an MDB, the New Values property of all AutoNumber
fields is changed from Increment to Random.
 
Ray said:
Why doesn't it work in my replicated "design
master", or "replica" databases?

When you replicated your database, your AutoNumber was changed from
incremental to random, hon. That way when the replicas sync data, they don't
all use the same numbers and overwrite the wrong records.

If you don't understand the wisdom of this, say you were allowed to use
incremental AutoNumbers and henceforth set the seed to 497, the next higher
number from the last record, and you had three replicas. When they later
sync data this is what the replicas might look like:

Replica #1:
ID FirstName LastName Contribution
------------------------------------------------
497 Spencer Tracy $90
498 Sidney Poitier $75
499 Katharine Hepburn $100

Replica #2:
ID FirstName LastName Contribution
------------------------------------------------
497 Humphrey Bogart $80
498 Ingrid Bergman $100
499 Peter Lorre $75

Replica #3:
ID FirstName LastName Contribution
------------------------------------------------
497 George Peppard $100
498 Audrey Hepburn $75

If the replicas were synced in the order of #1, #2 and then #3, then the
master would contain the following records:

Master:
ID FirstName LastName Contribution
------------------------------------------------------------
497 George Peppard $100
498 Audrey Hepburn $75
499 Peter Lorre $75

Actually, there should have been 8 new records added to the master, but the
AutoNumbers in the replicas only had 497, 498, and 499 as the ID's, so five
records would have been overwritten as each subsequent replica was synced.
Not what we want to happen, hon.
 
That all sounds reasonable in the type of database I would never need. Mine
is an accounting database that requires line numbers to be sequential
starting from 1. I thought the changeseed was useful. There are no multiple
replicas synchronizing to the design master. The only reason I did it was
that when I work from home it takes too long to transfer information from the
server at work. I'll figure out a different solution, but it's disheartening
to know that when you change a database to replica, I can't un-replicate it.
I think I can recover my original from the server backup, but the whole thing
has been a minor nightmare.
 
By the Way,

The Autonumber is NOT changed to random in the design master, yet my
changeseed function does not work in it when all information is processed
from the master. Seeing as the "wisdom" of changing to random presupposes
that there would be multiple replicas (a neither neccessary nor required
supposition), does your fount of wisdom have an explanation for that, hon?
 
I looked at the design master, and the Autonumber has not been changed from
increment to random there. A useful function of using a replica is that for
which I was using it. I can input information from home without connecting to
the server - too slow - then syncronize with the design master at work. If I
only have one replica, there is no problem with conflicting syncronizations.
In addition, if I process all information from the design master (where the
Autonumber is incremental and not random), the changeseed function still does
not work. I'm trying to understand this. Any help? Although I think I'm gonna
try a different solution not using the changeseed anymore.
 
As a test, I created a replica of an existing, non-replicated MDB. Access
warned me that this would convert the MDB to a design master, and that this
would make changes to the database, and offered to make a back-up copy of
the MDB for me. It created this MDB in the same folder as the original MDB,
with the same name but with an extension of '.BAK'. If you want to restore
your MDB as it was before you replicated it, you might want to look for that
..BAK file.

The New Values property of all AutoNumber fields in the design master was
changed from Increment to Random. Note that this does not change the values
stored in AutoNumber fields in existing records, but the values assigned to
new records will be random. This is what I meant when I wrote that the
changeseed function would serve no useful purpose in a replicated MDB.

I would not recommend using AutoNumbers if you want sequential numbers. Try
the following KB article instead ...

http://support.microsoft.com/kb/210194/en-us

For more information about replication, see the following KB article, which
provides an overview as well as a link to an in-depth white paper on the
subject.

http://support.microsoft.com/kb/208774/en-us

Good luck.
 
Ray S. wrote:> Mine
is an accounting database that requires line numbers to be sequential
starting from 1.

If they must be sequential, then you definitely shouldn't try to use an
incremental AutoNumber, because these numbers aren't guaranteed to be
sequential. Instead, you can create your own custom sequential numbering
function to create numbers for each record, or you can add a Date/Time column
for the record's creation date and time, then run SELECT queries that sort
the records chronologically and add the appropriate line number for each
record.
it's disheartening
to know that when you change a database to replica, I can't un-replicate it.

Don't despair, hon. Try the TSI un-replicator utility:

http://www.trigeminal.com/lang/1033/utility.asp?ItemID=7#7
 
Ray said:
The Autonumber is NOT changed to random in the design master

My experience has been that the autoincremented values are random for any new
records created after the database was replicated, and the Access Online Help
says: "When you replicate a database, any incremental AutoNumber fields in
your tables change to random numbering. All AutoNumber fields in existing
records retain their values, but AutoNumber values for inserted records are
random," which confirms my experience. Hon, I don't know why your new
records aren't randomly incremented like everyone else's, unless your Design
Master is corrupted. Replicated databases are prone to corruption, so this
may be an idea you want to explore further.
Seeing as the "wisdom" of changing to random presupposes
that there would be multiple replicas (a neither neccessary nor required
supposition), does your fount of wisdom have an explanation for that, hon?

In the real world, limiting replication to only one replica per Design Master
wouldn't be very useful. Multiple replicas are often required in many
business environments, even though your current situation has no need for
multiple replicas.

Access replication is fraught with problems, so I'd recommend that you either
use another database engine's replication or use queries to sync the data.
 
Granny,

I don't know why you are so patronizing, or in what "real world" you live,
but I work for a company that does 75 billion in international business. I
think that's a pretty real company. If you can't relate to what I was doing,
then I'm not sure you're living in a real world. On the other hand, I don't
know what to tell you other than what I see in front of me. You said the
Autonumber would change from increment to random. I did not do so in the
design master. That's a fact. I asked what explanation you might have. All
you came back with was more condescending and unuseful commentary extolling
your "experience". You presumed that my records are not randomly incremented
"like everybody elses", which means you were not paying any attention. That
is precisely the problem and the result that I don't want. I have one
replica. It is merely used to input data at home and then syncronize it with
my work database. Gee, that doesn't sound like a very real world problem that
many workers might have, does it? As it turns out, I have already gone way
past this and found another solution; but you were not only not helpful, but
insultingly self-aggrandizing.
 
I don't know why you are so patronizing

I looked at some of the previous questions you've posted and found that you
would probably have an easier time assimilating the incongruity if I gave you
a little extra explanation, instead of just a short answer. My posts weren't
intended to be patronizing, so I'm sorry you categorized them this way.
I work for a company that does 75 billion in international business.

Apparently no one has had the heart to tell you that your company has had a
serious reversal of fortune. Your company reported annual revenues, both
foreign and domestic, of only $7.64 billion through June 30th to the SEC. My
condolences if your job is affected by such a devastating downtrend in
corporate revenues. Actually, I can't think of any company that has ever
lost almost $70 billion in annual business and survived, so I hope you have
your resume up to date and you have a 401K, not a future pension you're
depending on.
If you can't relate to what I was doing,
then I'm not sure you're living in a real world. . . . I asked what explanation
you might have. All you came back with was more condescending and
unuseful commentary extolling your "experience".

I can probably relate to what you're doing, since I've worked for three very
large organizations, each with 200,000 - 300,000+ personnel. So I've seen
tens of thousands of home-grown Access databases over the years in the IS/IT
departments, a good number of them replicated, and some of them I even built
myself. I haven't seen any AutoNumbers in replicated databases that were set
to "Increment" instead of "Random," nor do I find any other reports of this
by Googling for this problem. The only plausible explanation I have for your
case is that your Design Master is corrupt, which might happen if you don't
have the right service packs installed on both your work computer and the one
you use at home, or if you're not transporting the replicated database from
work to home and back to work again on a laptop so that the computer name and
file path are always the same at work and at home.

For the majority of replicas I've seen throughout the many departments and
organizations I've been in or been associated with that were using
replication, multiple replicas are the rule, not the exception. Each
organization has multiple satellite offices and multiple people that spend
time on the road with their laptops, and they all need to sync their data
with the home office. When it comes to data in these organizations, the
databases are shared and highly integrated resources, so there are very few
*lone wolves* (single users who are the only ones who need to sync their data)
. Almost none of these organizations would use Access replication if they
could only create and sync one replica, because they'd find it inadequate for
their needs.

You asked for help. You can listen to the advice of someone who has probably
built more replicated databases successfully than you have, and has seen more
replicated databases than you have, and has done some homework to cater
answers specifically for you. On the other hand, you can take the time to
earn that experience for yourself. It's up to you, hon.
You presumed that my records are not randomly incremented
"like everybody elses", which means you were not paying any attention. That
is precisely the problem and the result that I don't want.

What presumption? *You* told us your records are not randomly incremented,
so we took your word for it. Hon, I know you don't *want* random AutoNumbers,
but that's what everyone is *supposed* to get after replication, whether this
frosts your cake or not. You seem to be taking your anger out on me because
the Seed property can't be set on your AutoNumber field in your replicated
database (which means at least that part is working as designed, even if you
don't see "Random" in the "New Values" property in the table's Design View).

A word to the wise: if you find that Access is acting crazy, but only for
one application, or you have an application that does something that no one
else's application does, or you have an application that doesn't act in some
way like everyone else's, it's a prime indicator that you may have a corrupt
file on your hands. Or you've made a colossal boo boo in your code.
As it turns out, I have already gone way
past this and found another solution;

Good for you! I'm glad you've succeeded in doing what you needed to get done.
Did you go with the linked table in an unreplicated database file, which is
the simplest way to keep a non-randomly incremented AutoNumber after
replication, as long as you don't need to enforce referential integrity for
that table?
you were not only not helpful, but
insultingly self-aggrandizing.

You say that I'm extolling my experience and being insultingly self-
aggrandizing. Let's just overlook the rude parts and the part about bragging
of working for a company that does $75 billion in international business.
You're free to ask for and take the advice of people who are merely guessing
at what your problem is if that's easier to swallow than someone telling you
"what my experience has been when I was in your shoes." I, for one, won't be
wasting my time in the future by offering you advice, providing examples to
explain concepts, or supplying links to free tools to help you get your job
done faster and easier.
 
You're free to ask for and take the advice of people who are merely guessing
at what your problem is if that's easier to swallow than someone telling you
"what my experience has been when I was in your shoes." I, for one, won't be
wasting my time in the future by offering you advice, providing examples to
explain concepts, or supplying links to free tools to help you get your job
done faster and easier.

Of course, if you felt that you were merely guessing at what my problem was,
you should have asked for more information, instead of taking the opportunity
to talk about how when you were young you used to walk seven miles to school,
"hon". I am very thankful and grateful that you won't be "wasting your time"
in the future with me.
 
Ray said:
Of course, if you felt that you were merely guessing at what my problem was,
you should have asked for more information, instead of taking the opportunity
to talk about how when you were young you used to walk seven miles to school,
"hon". I am very thankful and grateful that you won't be "wasting your time"
in the future with me.

You know I wasn't guessing. You gave all the information that was necessary.

And it was only a couple of miles to school when I was a child. But it was
through the snow. In a skirt. Uphill. Both ways.

Some day you'll be old and gray, too, and the shoe will be on the other foot.
But don't worry, hon. People in my family are very long lived, so I'll still
be around to laugh with you about it. : )
 
I think the point in an accounting system using autonombers is to assure
transparency, that nothing was deleted. Which is why you can not use your
"own" numbering system nor random numbering.
I find the use of "hon" adressing somebody you are trying to explain
something to, to be parallel to the use of "pat" adressing an irish person or
"boy" adressing a coloured person. So don't.
Opfør jer ordentligt ellers er der ingen tur til legoland!

"Granny Spitz via AccessMonster.com" skrev:
 
Any system which never allows deletion promotes inaccuracy. What a good
accounting system does is to assure an audit trail of those items which are
deleted. The easiest was to do that is to flag items as deleted, and not
actually delete them. Subsequent queries and reports can then leave out the
"deleted" data with a simple Where clause.
 
Back
Top