I have a database that has had some problems in the past, but for the
last several weeks has been quite stable.  It is used by 4 people
remotely connecting and is not being replicated (not published).

I want to try the replication idea again, starting out small and simple
where it simply saves all data off to the users' local hard disk so
that if they are disconnected, they could still get to their data
(read-only for now).

So I issued the PUBLISH DATABASE command listing all the tables I want
replicated and received Error 100 with the specific error: "Signature,
password, character set (ANSI/Unicode), or version number mismatch" for
a specific table.

I have made sure that both the server and my desktop are using EDB 2.02
B7.  I reverse-engineered the database to a SQL script, created a new
table with the same structure as the table encountering the error,
copied the data over to it, then deleted the original table.

Re-running the PUBLISH command gives the same error, but now at a
different table.  Feeling partial success, I repeat the process,
replacing each table with a new version of itself thinking that
eventually the problems will be eliminated because they must be in the
table structure header somehow.

After finally replacing the last table (I had run the PUBLISH command
between each set of files in case there were only a few with metadata
errors), I run the PUBLISH command again, and find to my horror that
I'm back at square one: the first table I "cleaned" is reporting the
same error 100.

Aaargh!  So it wasn't in the table structure after all?  Deleting and
recreating the tables probably just put them in a different order, I
guess, so that the error ended up on a different table.

So how do I get past this?  I can alter the tables and add constraints,
the users can work in standard client/server mode just fine all day.

Is the problem in the catalog or the configuration?  Is there a
metadata repair statement?


Thanks,

--
David Cornelius
CorneliusConcepts.com

David


Just tried PUBLISH DATABASE here, with and without the TABLES clause and no error message, no idea what it did either, but it said it did it successfully

The one I tried it on doesn't have any triggers, functions or procedures defined - does yours?

Roy Lambert

> Just tried PUBLISH DATABASE here, with and without the TABLES clause
> and no error message, no idea what it did either, but it said it did
> it successfully
>
> The one I tried it on doesn't have any triggers, functions or
> procedures defined - does yours?

Yes, but that's not the issue.  There is corruption in the
configuration or catalog.  That's what needs repaired.

--
David Cornelius
CorneliusConcepts.com

> So I issued the PUBLISH DATABASE command listing all the tables I want
> replicated and received Error 100 with the specific error: "Signature,
> password, character set (ANSI/Unicode), or version number mismatch"
> for a specific table.

One more thing to note:  I restored a backup of the database to a new
database and published it just fine.  So I tried dropping the original
database and restoring it from backup, but the same error reoccured.
Perhaps there were left over files in the folder--I didn't check.

--
David Cornelius
CorneliusConcepts.com

David,

<< So I issued the PUBLISH DATABASE command listing all the tables I want
replicated and received Error 100 with the specific error: "Signature,
password, character set (ANSI/Unicode), or version number mismatch" for a
specific table. >>

Can you actually open the table in question ?  It sounds like you've got
your files mixed up.  Have you been restoring or copying around the table
files recently ?  You have to be very careful when restoring files from
backups and make sure that you include the catalog during the restore, or
you'll end up with a mess on your hands.

--
Tim Young
Elevate Software
www.elevatesoft.com

> Can you actually open the table in question ?  It sounds like you've
> got your files mixed up.  Have you been restoring or copying around
> the table files recently ?  You have to be very careful when
> restoring files from backups and make sure that you include the
> catalog during the restore, or you'll end up with a mess on your
> hands.

Sorry I didn't see this until now.  With you out for a week, I found a
way around things by restoring to a totally new database.  Everything
worked fine, so I just dumped the old one.  I'm pretty sure the problem
was in the catalog, but it's gone now.

If I always need to restore the catalog, then how come there's a
checkbox to optionally restore it?  And why wouldn't that be checked by
default?  Oh well, the issue is past me now.  I probably messed things
up somewhere along the way!

--
David Cornelius
CorneliusConcepts.com

David,

<< If I always need to restore the catalog, then how come there's a checkbox
to optionally restore it? >>

A developer doesn't always need to restore it.  It only needs to be restored
if the catalog has changed since the table files were last backed up.
That's why it is optional and why it isn't checked by default.

--
Tim Young
Elevate Software
www.elevatesoft.com