(The following takes place in EDB Manager 2.01 build 3.  The EDB 2.01
b3 database server runs on Windows Server 2008 w/ 2 GB RAM and a large,
fast SATA HD.)

Earlier today, I created a trigger for a table on a new, remote
database, added some records, made a backup, then published the entire
database.  This database is live for a customer.

This evening, I restored the backup to a test database and published
that one as well so I could test development builds before releasing
application updates to the customer.

I tried to modify the trigger in the test database, but it timed out.
So I tried to create a new one and delete the one I had created, but
kept getting the same time-out. I thought maybe there was a restriction
with the fact the database was published, so I unpublished the database
and tried again--no go. I tried creating a new table, but that also
timed out.  However, viewing table structures, triggers, opening and
closing tables--all of this worked just fine, I just couldn't make any
more meta data changes.

Finally, I tried creating a new database on the remote server.  This
worked!  Then I added a table and a trigger and modified the trigger.
No problem.  So it must be a problem with the database, right?

I went back to the "troubled" database and tried to modify that same
trigger again.  This time it took it with no problem.


Very weird.


Well, this makes me wonder about something else that happened earlier
today...


Right after I had restored the customer's live database from their
backup onto the new EDB server, I deployed the first version of the new
application which was to create local stores, download a copy of the
database, and restore it locally.  My tests had accomplished this in
less than 2 minutes.  After two HOURS, we finally terminated it (they
have a slower internet connection and slower computers than I, but this
is obviously beyond just a speed issue).  We tried again with a
modified install that had status messages for every step of the way and
got a file read error.  With frustrations running high, and me running
out of ideas, we simply launched the install again immediately.  This
time it completed successfully in 1.5 minutes.

Go figure.


--
David Cornelius
CorneliusConcepts.com

David,

<< Right after I had restored the customer's live database from their backup
onto the new EDB server, I deployed the first version of the new application
which was to create local stores, download a copy of the database, and
restore it locally.  My tests had accomplished this in less than 2 minutes.
After two HOURS, we finally terminated it (they
have a slower internet connection and slower computers than I, but this is
obviously beyond just a speed issue).  We tried again with a modified
install that had status messages for every step of the way and got a file
read error.  With frustrations running high, and me running out of ideas, we
simply launched the install again immediately.  This time it completed
successfully in 1.5 minutes. >>

There is definitely something interfering with the comms and that server.
Did you check for software firewalls, scanners, etc. ?

BTW, in cases like this, you should try to record the error messages so that
I can help you further.  Any errors that are caused by external factors
always include the OS error code/message from the system, and that helps to
isolate the issue very quickly.

--
Tim Young
Elevate Software
www.elevatesoft.com

> There is definitely something interfering with the comms and that
> server. Did you check for software firewalls, scanners, etc. ?
>
> BTW, in cases like this, you should try to record the error messages
> so that I can help you further.  Any errors that are caused by
> external factors always include the OS error code/message from the
> system, and that helps to isolate the issue very quickly.

No, I didn't check software firewalls, etc.  Mostly because nothing
changed and simply re-running it worked successfully.  I did write down
the error at one point, but after everything started working, threw it
away (silly me).  Most of the time, there was no error--the server just
never responded.

There are lots of mysterious things on the networking side of things
(IMO).  This morning, two of the computers in my home network could not
see the LAN server, but the server could see the internet just fine.
Even rebooting the workstations did not help, but then later they just
started working magically.  I keep all software updated, and have a
good anti-virus checker.  I am diligent about watching what software is
being run on my computer, practice safe browsing, and monitor processes
frequently.

But still, things like this happen too frequently--enough to keep me
humble, I guess.  (It also helps me believe my relatives when they tell
me their internet just stopped working for no reason!)


--
David Cornelius
CorneliusConcepts.com

David,

<< No, I didn't check software firewalls, etc.  Mostly because nothing
changed and simply re-running it worked successfully.  I did write down the
error at one point, but after everything started working, threw it away
(silly me).  Most of the time, there was no error--the server just never
responded. >>

This is usually a very good indication that there's a network issue,
especially if you don't restart the ElevateDB Server and it works fine on
the second run.  Was this the case, or did you restart the EDB Server ?

<< There are lots of mysterious things on the networking side of things
(IMO).  This morning, two of the computers in my home network could not see
the LAN server, but the server could see the internet just fine. Even
rebooting the workstations did not help, but then later they just started
working magically.  I keep all software updated, and have a
good anti-virus checker.  I am diligent about watching what software is
being run on my computer, practice safe browsing, and monitor processes
frequently. >>

Is any of this wireless ?

--
Tim Young
Elevate Software
www.elevatesoft.com

> This is usually a very good indication that there's a network issue,
> especially if you don't restart the ElevateDB Server and it works fine on
> the second run.  Was this the case, or did you restart the EDB Server ?

No, I did not restart the EDB server.  I wanted to know whether it was just
that database, my Windows server, networking cable, the router, or what.
When I was able to create and make changes on a new test database, that
eliminated a lot of external possibilities.

> Is any of this wireless ?

No--it's all wired.  And everything else network-wise still worked.  In
fact, I was watching video clips on hulu.com while waiting for the database
server to connect (or timeout)!

Oh well, everything seems to be working now.  My customer is actually
synchronizing for the first time today and we're seeing replicated records
on the server!  I'm very excited.  

--
David Cornelius
CorneliusConcepts.com

David,

<< No, I did not restart the EDB server.  I wanted to know whether it was
just that database, my Windows server, networking cable, the router, or
what. When I was able to create and make changes on a new test database,
that  eliminated a lot of external possibilities. >>

If the ElevateDB Server was otherwise running fine, and ran fine on
subsequent runs without restarting it, then there was a network glitch or
something else external.  If there's an issue with the ElevateDB Server that
causes that level of severe slowdown, it is almost always reproducible when
you run the process a second and third time.  That's one thing about
database engines - when they fail, they usually fail pretty consistently.


<< No--it's all wired.  And everything else network-wise still worked.  In
fact, I was watching video clips on hulu.com while waiting for the database
server to connect (or timeout)! >>

I'm assuming in all of this that the ElevateDB Server is being accessed over
the Internet.  Is that correct ?  If so, then it could definitely be a
network issue between the point of connection and the ElevateDB Server.
Sometimes you can see slowdowns and outages for no apparent reason, and the
most likely cause is a failure somewhere along the line that isn't obvious.

<< Oh well, everything seems to be working now.  My customer is actually
synchronizing for the first time today and we're seeing replicated records
on the server!  I'm very excited.  >>

Cool.  When you get some free time you should write up a short case study
for us (hint..hint .

--
Tim Young
Elevate Software
www.elevatesoft.com

> If the ElevateDB Server was otherwise running fine, and ran fine on
> subsequent runs without restarting it, then there was a network glitch or
> something else external.  If there's an issue with the ElevateDB Server
> that causes that level of severe slowdown, it is almost always
> reproducible when you run the process a second and third time.  That's one
> thing about database engines - when they fail, they usually fail pretty
> consistently.

That's good.  I like consistency and reproducability--especially in
failures!


> I'm assuming in all of this that the ElevateDB Server is being accessed
> over the Internet.  Is that correct ?  If so, then it could definitely be
> a network issue between the point of connection and the ElevateDB Server.
> Sometimes you can see slowdowns and outages for no apparent reason, and
> the most likely cause is a failure somewhere along the line that isn't
> obvious.

The first part of the problem was while I was working late in the evening
from my home office and the server is within my home office, so it was
within my LAN.  But the next day when my customer was having issues, yes it
was through the internet.  There were probably two separate problems whose
coincidence influenced my uncertainty.

My new Windows 2008 Server is a primary domain controller, but my main
desktop is still just a stand-alone XP machine (I haven't yet taken the time
to join it to the domain and move my settings to the networked user
profile).  I hook up to the server via a NET USE batch file. My computer
sometimes gets it's IP Address and gateway confused, even though it's
static.  I haven't taken the time to get to the bottom of it because I
figure it's partly to do with the fact that it's not a true member of the
domain.  However, that didn't at first trigger a warning bell because I was
still connected to the internet--or at least I had reconnected to the
internet.  Perhaps it was only the connection to the server that got messed
up...

The next day, it was probably just a temporary internet connection issue,
but I was still agitated from the night before, so I jumped to conclusions!
Well, it's not likely an EDB issue (which I'm glad for).  I'll make sure my
connection issues are solid before opening my big mouth again!


> << Oh well, everything seems to be working now.  My customer is actually
> synchronizing for the first time today and we're seeing replicated records
> on the server!  I'm very excited.  >>
>
> Cool.  When you get some free time you should write up a short case study
> for us (hint..hint .

Yeah, I might just do that!

--
David Cornelius
CorneliusConcepts.com

David Cornelius wrote:

> (The following takes place in EDB Manager 2.01 build 3.  The EDB 2.01
> b3 database server runs on Windows Server 2008 w/ 2 GB RAM and a
> large, fast SATA HD.)
>
> Earlier today, I created a trigger for a table on a new, remote
> database, added some records, made a backup, then published the entire
> database.  This database is live for a customer.
>
> This evening, I restored the backup to a test database and published
> that one as well so I could test development builds before releasing
> application updates to the customer.
>
> I tried to modify the trigger in the test database, but it timed out.
> So I tried to create a new one and delete the one I had created, but
> kept getting the same time-out. I thought maybe there was a
> restriction with the fact the database was published, so I
> unpublished the database and tried again--no go. I tried creating a
> new table, but that also timed out.  However, viewing table
> structures, triggers, opening and closing tables--all of this worked
> just fine, I just couldn't make any more meta data changes.
>
> Finally, I tried creating a new database on the remote server.  This
> worked!  Then I added a table and a trigger and modified the trigger.
> No problem.  So it must be a problem with the database, right?
>
> I went back to the "troubled" database and tried to modify that same
> trigger again.  This time it took it with no problem.
>
>
> Very weird.
>
>
> Well, this makes me wonder about something else that happened earlier
> today...
Another instance of this ocurred tonight, but less dramatic.  Here are
the details...

After reading the error message of a failed replication update (see my
"oops--replicated temp tables!" thread), I tried to modify the table
TempDetails (which is not really a temporary table, but a regular table
only used for temporary purposes).  The error had mentioned a primary
key, so I went to look at the table structure.

I found one index (not a primary key) and one weird looking
constraint--weird because it did not have a name.  In other words,
opening up the constraint list in EDB Manager shows one constraint icon
with no text by it.  In the Alter Table dialog, the constraints tab has
the first row with an aparent constraint in it, but no name.  The "Drop
constraint" button is enabled.  I tried to drop it, then save the
table, and got a #401 error, the constraint does not exist.

So I canceled altering the table and tried to drop the table.  That's
when the timeout ocurred.  While waiting for something to happen, I
quickly did some tests: 1) openend a shared folder on the
server--check; 2) opened a second copy of EDB Manager and connected to
another database on the server--check; 3) opened the same TempDetails
table in a "test" copy of the database and looked at its constraints
list--check; 4) altered the table and saw the same weird constraint
(still in the "test" database), tried to delete it, got the 401
message, canceled, dropped the table--check.  No problems.

By this time, a second timeout message appeared:

Error #1100  A connection to the server cannot be established ('Timed
out while receiving stream').


Some of fine points of these details may not be exactly right, but I
tried to recollect as many details as acurately as possible (was it the
2nd timeout message?  or the 3rd?).  Anyway, I'm happy to chalk this up
to just weird anomalies.  After all, I'm a database developer and work
with a lot of small integration projects in many environements that
have a myriad of configurations and possibilities of things going
wrong.  If it finally works, smile and go home!

But since this happened two nights in a row and since this is a new
installation for a customer that has waited a long time for me to
finish this project, and since replication is a new area for me, I'm
trying to learn as much as I can about how all this works.  Besides, I
really want everything to go right--I'd like to stop working 16-hour
days!


--
David Cornelius
CorneliusConcepts.com

> I found one index (not a primary key) and one weird looking
> constraint--weird because it did not have a name.  In other words,
> opening up the constraint list in EDB Manager shows one constraint
> icon with no text by it.  In the Alter Table dialog, the constraints
> tab has the first row with an aparent constraint in it, but no name.
> The "Drop constraint" button is enabled.  I tried to drop it, then
> save the table, and got a #401 error, the constraint does not exist.

Further messing around in EDB Manager makes me think that it might be a
simple EDB Manager UI issue.  I created a test table, one column,
NULLable, no constraints, no defaults, no indexes.  Saved.

Altered the table, went to the constraints tab and see the "Drop
constraint" button enabled.  Clicked it.  Verified I wanted to drop the
(non-existant) constraint.  Got error 401--the constraint does not
exist.

Yes, that was a ridiculous thing to do, but if I didn't know whether
there was a constraint or not, I would think looking in the constraints
tab of the alter table dialog would be an indicator: if a row is
selectable and the Drop Constraint button is enabled, there must be a
constraint there, right?

(*sigh*)  OK--I've driven this one far enough into the ground!


--
David Cornelius
CorneliusConcepts.com

David,

<< Further messing around in EDB Manager makes me think that it might be a
simple EDB Manager UI issue.  I created a test table, one column, NULLable,
no constraints, no defaults, no indexes.  Saved.

Altered the table, went to the constraints tab and see the "Drop
constraint" button enabled.  Clicked it.  Verified I wanted to drop the
(non-existant) constraint.  Got error 401--the constraint does not exist. >>

I'm not seeing this here at all.  Are you using 2.01 B4 ?


--
Tim Young
Elevate Software
www.elevatesoft.com