Or is it the other way around?

I have EDB Manager 2.01 b4 and was altering the structure of a table on
the server in my local LAN.  This table has about a 1000 rows, but no
primary key.  So I added an Integer ID (with auto generation) and wrote
a script to set each ID of the existing records to the next in a
sequence of numbers.  There were a few duplicates, so I cleaned those
out.

Good.  Now I can set it up to be a primary key and I'll be done.  Alter
table, add pk constraint, save.  Hmmm...  This is taking a while...
Oops: timeout!  Huh?  Pull up 2nd copy of EDB Manager, access other
tables in the same database, opening and closing to make sure nothing
is cached.  No problem, back to 1st one, try again...  timeout.  Grrr...

OK--I'll just shut down the service on the server and start it back up.
Ugh--now I can't open or alter the table:

 EDB Error #100: error in metadata (signature, password, char set,
 or version number mismatch).

Weird.  I can expand the columns and indexes.  I can expand the
constraints--wait, here it is again: a line for a contraint with the
constraint icon, but no name after it.  Same for triggers, but I never
added a trigger to this table.

Attempting a "repair" gives me the same error as above.

OK--I'll restore from backups.  But I didn't lose connection to the
server (that I know of), I'm working locally in my home office, I've
got all the updates on both server and workstation.


Is it me?

--
David Cornelius
CorneliusConcepts.com

David,

<< Or is it the other way around? >>

It doesn't matter either way - a timeout won't affect a metadata operation
since all metadata operations are SQL-based, meaning that they are sent to
the server and executed there.  It shouldn't matter what happens with the
client during such an operation.

<< Good.  Now I can set it up to be a primary key and I'll be done.  Alter
table, add pk constraint, save.  Hmmm...  This is taking a while... Oops:
timeout!  Huh?  Pull up 2nd copy of EDB Manager, access other tables in the
same database, opening and closing to make sure nothing is cached.  No
problem, back to 1st one, try again...  timeout.  Grrr... >>

What is the actual message that you're getting here ?  Is it the normal EDB
Manager timeout prompt, or an error message ?

<< OK--I'll just shut down the service on the server and start it back up.
Ugh--now I can't open or alter the table:

 EDB Error #100: error in metadata (signature, password, char set, or
version number mismatch). >>

Did you try just opening the table ?  Is this table published ?

<< Weird.  I can expand the columns and indexes.  I can expand the
constraints--wait, here it is again: a line for a contraint with the
constraint icon, but no name after it.  Same for triggers, but I never added
a trigger to this table.

Attempting a "repair" gives me the same error as above. >>

Can you reproduce this if you try the same steps again, irregardless of the
timeout ?

--
Tim Young
Elevate Software
www.elevatesoft.com

> It doesn't matter either way - a timeout won't affect a metadata
> operation since all metadata operations are SQL-based, meaning that
> they are sent to the server and executed there.  It shouldn't matter
> what happens with the client during such an operation.

Oh, you're right.  


> What is the actual message that you're getting here ?  Is it the
> normal EDB Manager timeout prompt, or an error message ?

The normal EDB Manager timeout.


> << OK--I'll just shut down the service on the server and start it
> back up. Ugh--now I can't open or alter the table:
>
> EDB Error #100: error in metadata (signature, password, char set, or
> version number mismatch). >>
>
> Did you try just opening the table ?  Is this table published ?

Yes:  "now I can't open or alter the table".  No, I had not yet
published the database.


> Can you reproduce this if you try the same steps again, irregardless
> of the timeout ?

No.  After restarting the server and restoring from backup (actually I
exported from another copy of the database and imported into this one),
I was able to re-add the constraint and everything is good now.

--
David Cornelius
CorneliusConcepts.com

David,

<< Yes:  "now I can't open or alter the table".  No, I had not yet published
the database. >>

Sorry, I missed the "open" part.

<< No.  After restarting the server and restoring from backup (actually I
exported from another copy of the database and imported into this one), I
was able to re-add the constraint and everything is good now. >>

Okay.  Please let me know if you see anything like this again.  Something's
not right, but I'm not sure what it is.  The only issue we've had that is
even remotely similar is this one in 2.00:

http://www.elevatesoft.com/incident?action=viewrep&category=edb&release=2.00&type=f&incident=2661

--
Tim Young
Elevate Software
www.elevatesoft.com

> Okay.  Please let me know if you see anything like this again.
> Something's not right, but I'm not sure what it is.  The only issue
> we've had that is even remotely similar is this one in 2.00:

OK, it happened again.  I was working from my XP-64 workstation against
a server database in my home office with Windows Server 2008 on the
LAN, and both machines have EDB 2.01 b4.  I had been doing a whole
bunch of work in EDB Mgr, modifying scripts, looking at values in
tables, etc.  I'm running through tests where I backup the server
database, copy it to staff stores, then run an install program (as a
new staff member) that downloads the backup to a local store, restores
it, and runs the program against the local copy of the database.  I'm
ready to test saving/uploading/loading updates for the replication part
between a couple of computers.

So to set everything up, I have a script on the server that unpublishes
the database, sets a value back to default in the Staff table, does the
backup and copies the backup to all the staff stores.  I've been
running this over and over, of course, during my testing.

But this time, as soon as I ran it, it just hung.  Eventually, it came
back and gave me the time out message.  I said No to keep connected and
try again, at which point it hung again (as usual).  The second time it
gives me the timeout message, it always finally lets me go on.  So the
first thing I tried to do after EDB Mgr is usable again, is to open a
table.  EDB Mgr lets me expand the table icon to see columns and
indexes and so forth, but if I try to Open or Repair the table, I get:

 Error #100: Error in metadata (sig, pw, char set, or vr mismatch).

This happens for every single table in the database.  My only recourse
is to restore from backup.  After that, no problem, I'm back in
business.

I usually work late in the evening (I'm in Oregon and the timestamp on
these messages give that away) and I didn't record exactly when I
started that script, but could it possibly be a date roll-over issue?
I might have started it exactly at midnight.  I can't imagine this
would be an issue, but I'm reaching at possibilities.

I've also started looking through the event log on the Windows Server.
I'm not a sysadmin, so some of that is beyond me, but I do notice some
Active Directory errors, mostly having to do with DNS.  Probably
nothing to do with this, but you never know.

--
David Cornelius
CorneliusConcepts.com

David,


<< But this time, as soon as I ran it, it just hung.  Eventually, it came
back and gave me the time out message.  I said No to keep connected and try
again, at which point it hung again (as usual).  The second time it gives me
the timeout message, it always finally lets me go on.  So the first thing I
tried to do after EDB Mgr is usable again, is to open a
table.  EDB Mgr lets me expand the table icon to see columns and indexes
and so forth, but if I try to Open or Repair the table, I get:

 Error #100: Error in metadata (sig, pw, char set, or vr mismatch).

This happens for every single table in the database.  My only recourse is
to restore from backup.  After that, no problem, I'm back in business. >>

This most likely means that the catalog is corrupted, which is just about
impossible to do without some serious disk errors and/or interference from
something external.  The catalog is updated in this fashion:

- Make copy of catalog
- Flush copy to disk
- Write new version of catalog

So, something must be screwing with the third step.  Are you running any
automated AV software, backup software, etc. on the server ?

--
Tim Young
Elevate Software
www.elevatesoft.com

> This most likely means that the catalog is corrupted, which is just about
> impossible to do without some serious disk errors and/or interference from
> something external.  The catalog is updated in this fashion:
>
> - Make copy of catalog
> - Flush copy to disk
> - Write new version of catalog
>
> So, something must be screwing with the third step.  Are you running any
> automated AV software, backup software, etc. on the server ?


AV: Just Windows Defender that comes with Windows Server 2008.  I'll be
upgrading my single-user version of Nod32 to a network version soon.  That's
probably better.

Backup: not yet defined.

Defrag: 1:00 AM every Wednesday.  Hmm... I should change that time.

Nothing else much.  I don't have Exchange, but do have MS SQL Server 2005
(seldom used).  A friend remotes in sometimes using Terminal Services.  IIS
is not installed.

I'll keep watch and probably get to the bottom of this some day.  I don't
think at all anymore that this is an EDB problem.

--
David Cornelius
CorneliusConcepts.com

David,

<< I'll keep watch and probably get to the bottom of this some day.  I don't
think at all anymore that this is an EDB problem. >>

Well, it's always quite possible that it is.  Just to confirm - do you have
the sequence of steps/events that causes the issue ?  Or is it still a bit
gray ?

--
Tim Young
Elevate Software
www.elevatesoft.com

> Well, it's always quite possible that it is.  Just to confirm - do you
> have the sequence of steps/events that causes the issue ?  Or is it still
> a bit gray ?


It's different every time--there is no pattern.  I'll be working fine for
hours, then, like last night, be ready to do one final backup and run a
script I've run dozens of times, and it will just decide to lockup.

Last night (or was it the night before now?), the script actually backed up
the database before locking up.  After it came back to life, I saw that it
had actually executed part of the script.  I guess a question following that
would be: does EDB Manager send the whole script at once to be executed or
give one statement at a time?  (I should know the answer to this...)  If the
latter, we're no further, because the network or server or something just
hiccups once in a while.  But if the server gets the whole script at once,
then it's strange that it would lock up after executing part of it.

Unfortunately, it's not reproducible.  And most of the time everything hums
along just fine.  I guess it's just one of those mysteries of computing I
hope the customer never questions too far!

--
David Cornelius
CorneliusConcepts.com

David,

<< I guess a question following that would be: does EDB Manager send the
whole script at once to be executed or
give one statement at a time? >>

It sends the whole script to be executed.  DBISAM does it
statement-by-statement.

<< But if the server gets the whole script at once, then it's strange that
it would lock up after executing part of it. >>

Can you show me the script that locked up, and where it locked up ?  It
sounds like a locking issue, especially if you're talking about backups.

--
Tim Young
Elevate Software
www.elevatesoft.com