Disk I/O

I would like to confirm what Perfmon counters I should be looking at to esta
blish if the system running our Production Instance of SQL Server, has an I/
O bottleneck. I have been focusing on Current Disk Queue Length counter whic
h during peak times (a 2.5
hour interval) peaks around 200+ for extended intervals. We have storage on
a SAN (EMC disk array with RAID 10). The databases reside (both data and tra
nsaction logs) on a single logical drive that comprises of 4 physical disks
on the EMC. Current queue l
ength of 200+ (for extended periods of time) seems like a problem, but Micro
soft expert says that we should be looking at Avg Queue Length counter. I ne
ed to know what counters can help us determine if in fact there is I/O bottl
eneck
Thanks, ShehlaI agree that looking at average disk queue might give a better overall
picture but if your getting current disk queues of 200+ for extended periods
of time that will be an issue. You should also check with who ever
maintains the SAN to see what tools they have for monitoring the disk
activity.
Andrew J. Kelly SQL MVP
"Shehla Arshad" <anonymous@.discussions.microsoft.com> wrote in message
news:D46831D9-D706-4944-ADC4-FEBCBE13CFE8@.microsoft.com...
> I would like to confirm what Perfmon counters I should be looking at to
establish if the system running our Production Instance of SQL Server, has
an I/O bottleneck. I have been focusing on Current Disk Queue Length counter
which during peak times (a 2.5 hour interval) peaks around 200+ for extended
intervals. We have storage on a SAN (EMC disk array with RAID 10). The
databases reside (both data and transaction logs) on a single logical drive
that comprises of 4 physical disks on the EMC. Current queue length of 200+
(for extended periods of time) seems like a problem, but Microsoft expert
says that we should be looking at Avg Queue Length counter. I need to know
what counters can help us determine if in fact there is I/O bottleneck
> Thanks, Shehla|||In addition to Andrew's comments... average disk q is better, and average
queue > 2 is bad... However the number that comes from perfmon is for the
drive letter... you must divide the perfmon number (200) by the number of
physical drives behind the letter, (4), so your average queueing is still
50( way too high.)
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Shehla Arshad" <anonymous@.discussions.microsoft.com> wrote in message
news:D46831D9-D706-4944-ADC4-FEBCBE13CFE8@.microsoft.com...
> I would like to confirm what Perfmon counters I should be looking at to
establish if the system running our Production Instance of SQL Server, has
an I/O bottleneck. I have been focusing on Current Disk Queue Length counter
which during peak times (a 2.5 hour interval) peaks around 200+ for extended
intervals. We have storage on a SAN (EMC disk array with RAID 10). The
databases reside (both data and transaction logs) on a single logical drive
that comprises of 4 physical disks on the EMC. Current queue length of 200+
(for extended periods of time) seems like a problem, but Microsoft expert
says that we should be looking at Avg Queue Length counter. I need to know
what counters can help us determine if in fact there is I/O bottleneck
> Thanks, Shehla

Disk I/O

I would like to confirm what Perfmon counters I should be looking at to establish if the system running our Production Instance of SQL Server, has an I/O bottleneck. I have been focusing on Current Disk Queue Length counter which during peak times (a 2.5 hour interval) peaks around 200+ for extended intervals. We have storage on a SAN (EMC disk array with RAID 10). The databases reside (both data and transaction logs) on a single logical drive that comprises of 4 physical disks on the EMC. Current queue length of 200+ (for extended periods of time) seems like a problem, but Microsoft expert says that we should be looking at Avg Queue Length counter. I need to know what counters can help us determine if in fact there is I/O bottlenec
Thanks, ShehlaI agree that looking at average disk queue might give a better overall
picture but if your getting current disk queues of 200+ for extended periods
of time that will be an issue. You should also check with who ever
maintains the SAN to see what tools they have for monitoring the disk
activity.
--
Andrew J. Kelly SQL MVP
"Shehla Arshad" <anonymous@.discussions.microsoft.com> wrote in message
news:D46831D9-D706-4944-ADC4-FEBCBE13CFE8@.microsoft.com...
> I would like to confirm what Perfmon counters I should be looking at to
establish if the system running our Production Instance of SQL Server, has
an I/O bottleneck. I have been focusing on Current Disk Queue Length counter
which during peak times (a 2.5 hour interval) peaks around 200+ for extended
intervals. We have storage on a SAN (EMC disk array with RAID 10). The
databases reside (both data and transaction logs) on a single logical drive
that comprises of 4 physical disks on the EMC. Current queue length of 200+
(for extended periods of time) seems like a problem, but Microsoft expert
says that we should be looking at Avg Queue Length counter. I need to know
what counters can help us determine if in fact there is I/O bottleneck
> Thanks, Shehla|||In addition to Andrew's comments... average disk q is better, and average
queue > 2 is bad... However the number that comes from perfmon is for the
drive letter... you must divide the perfmon number (200) by the number of
physical drives behind the letter, (4), so your average queueing is still
50( way too high.)
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Shehla Arshad" <anonymous@.discussions.microsoft.com> wrote in message
news:D46831D9-D706-4944-ADC4-FEBCBE13CFE8@.microsoft.com...
> I would like to confirm what Perfmon counters I should be looking at to
establish if the system running our Production Instance of SQL Server, has
an I/O bottleneck. I have been focusing on Current Disk Queue Length counter
which during peak times (a 2.5 hour interval) peaks around 200+ for extended
intervals. We have storage on a SAN (EMC disk array with RAID 10). The
databases reside (both data and transaction logs) on a single logical drive
that comprises of 4 physical disks on the EMC. Current queue length of 200+
(for extended periods of time) seems like a problem, but Microsoft expert
says that we should be looking at Avg Queue Length counter. I need to know
what counters can help us determine if in fact there is I/O bottleneck
> Thanks, Shehlasql

Disaster Recovery plan for SQL server

Hi,
We plan to implement Disaster Recovery plan and system
for SQL 2000 server and databases. SQL server is
connected in headquarter network. Recovery SQL server
will stay on remote location (site) and it must have the
most recent copy of SQL production databases.
SQL server has 2 databases. Each database has about 2-3
GB of data. We can expect that database will grow
significantly in the future (10 Gb and more). Databases
accept about 2 MB of data per day. Connection between
headquarter and remote location will probably be on high-
speed WAN (10 Mb/s or more). At any disaster event, we
can loose data for about last 1 hour (maximum 1 hour, not
more anyway)
What is the best solution for implementing Disaster
Recovery?
Backup, restore with STANDBY server on remote location
(with frequently created transaction log backups)?
Or SQL database replication (transaction replication)?
Thanks in advance for help
MilanDefinitely Standby Server with Log Shipping.
Theres lots of info in SQL Books Online and it is offered as a feature with
SQL Enterprise Edition.
--
Regards,
Mandar Naik
This posting is provided AS IS with no warranties, and confers no rights.
"Milan Ojstersek" <milan.ojstersek@.hermes-plus.si> wrote in message
news:087a01c33f07$3e84d700$a301280a@.phx.gbl...
> Hi,
> We plan to implement Disaster Recovery plan and system
> for SQL 2000 server and databases. SQL server is
> connected in headquarter network. Recovery SQL server
> will stay on remote location (site) and it must have the
> most recent copy of SQL production databases.
> SQL server has 2 databases. Each database has about 2-3
> GB of data. We can expect that database will grow
> significantly in the future (10 Gb and more). Databases
> accept about 2 MB of data per day. Connection between
> headquarter and remote location will probably be on high-
> speed WAN (10 Mb/s or more). At any disaster event, we
> can loose data for about last 1 hour (maximum 1 hour, not
> more anyway)
> What is the best solution for implementing Disaster
> Recovery?
> Backup, restore with STANDBY server on remote location
> (with frequently created transaction log backups)?
> Or SQL database replication (transaction replication)?
> Thanks in advance for help
> Milan
>|||I prefer Log Shipping.
"Milan Ojstersek" <milan.ojstersek@.hermes-plus.si> wrote in message
news:087a01c33f07$3e84d700$a301280a@.phx.gbl...
> Hi,
> We plan to implement Disaster Recovery plan and system
> for SQL 2000 server and databases. SQL server is
> connected in headquarter network. Recovery SQL server
> will stay on remote location (site) and it must have the
> most recent copy of SQL production databases.
> SQL server has 2 databases. Each database has about 2-3
> GB of data. We can expect that database will grow
> significantly in the future (10 Gb and more). Databases
> accept about 2 MB of data per day. Connection between
> headquarter and remote location will probably be on high-
> speed WAN (10 Mb/s or more). At any disaster event, we
> can loose data for about last 1 hour (maximum 1 hour, not
> more anyway)
> What is the best solution for implementing Disaster
> Recovery?
> Backup, restore with STANDBY server on remote location
> (with frequently created transaction log backups)?
> Or SQL database replication (transaction replication)?
> Thanks in advance for help
> Milan
>

Disaster Recovery Plan

I have a server that has become unstable.
My tasks in the next 2 days:
Complete a full system backup of the source server
complete a full system restore to the destination server
unplug the old system
plug in the new system
Backup / Restore software: Veritas Backup Exec
Because of the nature of the production box, we have a No down time policy.
My concern is will replication be broken.
What might you suggest I prepare for?
Typically, you'll need to script out replication and reinitialize when you're
up and going on the new server. You can do a nosync initialization provided
all data has been synchronizes and then you have prevented access to the
system while this project is being done.
HTH,
Paul Ibison

Disaster Recovery

I am planing to implement a disaster recovery site for my enterprise system
consisting of database servers( sql server 2000) , web servers(IIS) and
application servers, all on microsoft platforms.
in case of any disaster it should failover to the other server in other site.
what about using third party solution like Neverfail or Xosoft ,Vertas
solution for achieving this.
which you recommend ?
Pls SHARE your opinion.
Note:cost is not a constarint.Take a look at
http://www.sql-server-performance.com/sql_server_log_shipping.asp
"bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote in
message news:385E5814-498C-429B-8A2D-3145EC2CFAFA@.microsoft.com...
>I am planing to implement a disaster recovery site for my enterprise system
> consisting of database servers( sql server 2000) , web servers(IIS) and
> application servers, all on microsoft platforms.
> in case of any disaster it should failover to the other server in other
> site.
> what about using third party solution like Neverfail or Xosoft ,Vertas
> solution for achieving this.
> which you recommend ?
> Pls SHARE your opinion.
> Note:cost is not a constarint.
>|||Hi uri,
I am already having cluster,log sipping, replication configured for database
but what i am looking for is a automatic failover to different site without
any data loss.
"Uri Dimant" wrote:
> Take a look at
> http://www.sql-server-performance.com/sql_server_log_shipping.asp
>
>
>
> "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote in
> message news:385E5814-498C-429B-8A2D-3145EC2CFAFA@.microsoft.com...
> >I am planing to implement a disaster recovery site for my enterprise system
> > consisting of database servers( sql server 2000) , web servers(IIS) and
> > application servers, all on microsoft platforms.
> > in case of any disaster it should failover to the other server in other
> > site.
> > what about using third party solution like Neverfail or Xosoft ,Vertas
> > solution for achieving this.
> >
> > which you recommend ?
> >
> > Pls SHARE your opinion.
> >
> > Note:cost is not a constarint.
> >
>
>|||If your requirements are automatic failover without data loss then ...
I understand that only Failover Clustering and Database Mirroring provide
automatic failover with no data loss. But failover clustering has only one
copy of the database. So, for your requirements that leaves database
mirroring as your only choice.
But here I am talking only about SQL Server technologies. I do not know
about choices from other vendors.
Benjamin Nevarez, MCDBA, OCP
"bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote in
message news:DB2A7267-4DC7-4827-B2E7-E2C00A81852B@.microsoft.com...
> Hi uri,
> I am already having cluster,log sipping, replication configured for
> database
> but what i am looking for is a automatic failover to different site
> without
> any data loss.
> "Uri Dimant" wrote:
>> Take a look at
>> http://www.sql-server-performance.com/sql_server_log_shipping.asp
>>
>>
>>
>> "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote
>> in
>> message news:385E5814-498C-429B-8A2D-3145EC2CFAFA@.microsoft.com...
>> >I am planing to implement a disaster recovery site for my enterprise
>> >system
>> > consisting of database servers( sql server 2000) , web servers(IIS) and
>> > application servers, all on microsoft platforms.
>> > in case of any disaster it should failover to the other server in other
>> > site.
>> > what about using third party solution like Neverfail or Xosoft ,Vertas
>> > solution for achieving this.
>> >
>> > which you recommend ?
>> >
>> > Pls SHARE your opinion.
>> >
>> > Note:cost is not a constarint.
>> >
>>|||Ben
Database Mirroring will be available for production only in the first half
2006.
"Ben Nevarez" <bnevarez@.sjm.com> wrote in message
news:%23Hg7NpX%23FHA.500@.TK2MSFTNGP15.phx.gbl...
> If your requirements are automatic failover without data loss then ...
> I understand that only Failover Clustering and Database Mirroring provide
> automatic failover with no data loss. But failover clustering has only one
> copy of the database. So, for your requirements that leaves database
> mirroring as your only choice.
> But here I am talking only about SQL Server technologies. I do not know
> about choices from other vendors.
> Benjamin Nevarez, MCDBA, OCP
>
>
> "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote in
> message news:DB2A7267-4DC7-4827-B2E7-E2C00A81852B@.microsoft.com...
>> Hi uri,
>> I am already having cluster,log sipping, replication configured for
>> database
>> but what i am looking for is a automatic failover to different site
>> without
>> any data loss.
>> "Uri Dimant" wrote:
>> Take a look at
>> http://www.sql-server-performance.com/sql_server_log_shipping.asp
>>
>>
>>
>> "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote
>> in
>> message news:385E5814-498C-429B-8A2D-3145EC2CFAFA@.microsoft.com...
>> >I am planing to implement a disaster recovery site for my enterprise
>> >system
>> > consisting of database servers( sql server 2000) , web servers(IIS)
>> > and
>> > application servers, all on microsoft platforms.
>> > in case of any disaster it should failover to the other server in
>> > other
>> > site.
>> > what about using third party solution like Neverfail or Xosoft ,Vertas
>> > solution for achieving this.
>> >
>> > which you recommend ?
>> >
>> > Pls SHARE your opinion.
>> >
>> > Note:cost is not a constarint.
>> >
>>
>|||I know. But it is December already, so right now it is a good time to test
the technology.
In addition, the original request mentions a SQL Server 2000 instalation.
So, in order to get benefit of database mirroring an upgrade is required,
isn't?
Ben Nevarez, MCDBA, OCP
Database Administrator
"Uri Dimant" wrote:
> Ben
> Database Mirroring will be available for production only in the first half
> 2006.
>
> "Ben Nevarez" <bnevarez@.sjm.com> wrote in message
> news:%23Hg7NpX%23FHA.500@.TK2MSFTNGP15.phx.gbl...
> >
> > If your requirements are automatic failover without data loss then ...
> >
> > I understand that only Failover Clustering and Database Mirroring provide
> > automatic failover with no data loss. But failover clustering has only one
> > copy of the database. So, for your requirements that leaves database
> > mirroring as your only choice.
> >
> > But here I am talking only about SQL Server technologies. I do not know
> > about choices from other vendors.
> >
> > Benjamin Nevarez, MCDBA, OCP
> >
> >
> >
> >
> > "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote in
> > message news:DB2A7267-4DC7-4827-B2E7-E2C00A81852B@.microsoft.com...
> >> Hi uri,
> >> I am already having cluster,log sipping, replication configured for
> >> database
> >> but what i am looking for is a automatic failover to different site
> >> without
> >> any data loss.
> >>
> >> "Uri Dimant" wrote:
> >>
> >> Take a look at
> >> http://www.sql-server-performance.com/sql_server_log_shipping.asp
> >>
> >>
> >>
> >>
> >>
> >>
> >> "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote
> >> in
> >> message news:385E5814-498C-429B-8A2D-3145EC2CFAFA@.microsoft.com...
> >> >I am planing to implement a disaster recovery site for my enterprise
> >> >system
> >> > consisting of database servers( sql server 2000) , web servers(IIS)
> >> > and
> >> > application servers, all on microsoft platforms.
> >> > in case of any disaster it should failover to the other server in
> >> > other
> >> > site.
> >> > what about using third party solution like Neverfail or Xosoft ,Vertas
> >> > solution for achieving this.
> >> >
> >> > which you recommend ?
> >> >
> >> > Pls SHARE your opinion.
> >> >
> >> > Note:cost is not a constarint.
> >> >
> >>
> >>
> >>
> >
> >
>
>|||Hi Guys,
any body used third party tools like veritas,nevefail or xosoft to achieve
this.
"Ben Nevarez" wrote:
> I know. But it is December already, so right now it is a good time to test
> the technology.
> In addition, the original request mentions a SQL Server 2000 instalation.
> So, in order to get benefit of database mirroring an upgrade is required,
> isn't?
> Ben Nevarez, MCDBA, OCP
> Database Administrator
>
> "Uri Dimant" wrote:
> > Ben
> > Database Mirroring will be available for production only in the first half
> > 2006.
> >
> >
> >
> > "Ben Nevarez" <bnevarez@.sjm.com> wrote in message
> > news:%23Hg7NpX%23FHA.500@.TK2MSFTNGP15.phx.gbl...
> > >
> > > If your requirements are automatic failover without data loss then ...
> > >
> > > I understand that only Failover Clustering and Database Mirroring provide
> > > automatic failover with no data loss. But failover clustering has only one
> > > copy of the database. So, for your requirements that leaves database
> > > mirroring as your only choice.
> > >
> > > But here I am talking only about SQL Server technologies. I do not know
> > > about choices from other vendors.
> > >
> > > Benjamin Nevarez, MCDBA, OCP
> > >
> > >
> > >
> > >
> > > "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote in
> > > message news:DB2A7267-4DC7-4827-B2E7-E2C00A81852B@.microsoft.com...
> > >> Hi uri,
> > >> I am already having cluster,log sipping, replication configured for
> > >> database
> > >> but what i am looking for is a automatic failover to different site
> > >> without
> > >> any data loss.
> > >>
> > >> "Uri Dimant" wrote:
> > >>
> > >> Take a look at
> > >> http://www.sql-server-performance.com/sql_server_log_shipping.asp
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> "bijupg@.hotmail.com" <bijupghotmailcom@.discussions.microsoft.com> wrote
> > >> in
> > >> message news:385E5814-498C-429B-8A2D-3145EC2CFAFA@.microsoft.com...
> > >> >I am planing to implement a disaster recovery site for my enterprise
> > >> >system
> > >> > consisting of database servers( sql server 2000) , web servers(IIS)
> > >> > and
> > >> > application servers, all on microsoft platforms.
> > >> > in case of any disaster it should failover to the other server in
> > >> > other
> > >> > site.
> > >> > what about using third party solution like Neverfail or Xosoft ,Vertas
> > >> > solution for achieving this.
> > >> >
> > >> > which you recommend ?
> > >> >
> > >> > Pls SHARE your opinion.
> > >> >
> > >> > Note:cost is not a constarint.
> > >> >
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
> >

Disappearing Records

I am running an Access 2000 MDB against a SQL 7 back end, using ODBC linked
tables over a LAN and a WAN. The system has been operational for years with
relatively few problems.

Recently, WAN users have been reporting several hundred records disappearing
at a time. The records are all sequential, and they're in a table that
contains about 60,000 records. This all started last week at about the same
time (not sure if before or after) that the WAN went down for a couple of
hours for an unknown reason. Since then, every once in a while, a WAN user
will report that several hundred records in a block are just "missing."
Then, an hour or two later, they reappear.

Any ideas as to what's going on or what can be done to rectify this?

Thanks!

Neilhi Neil,

Neil wrote:

Quote:

Originally Posted by

Any ideas as to what's going on or what can be done to rectify this?

Bad WLAN performance, but the network stack is not aware of it. So your
session thinks it is okay, but it's not.

mfG
--stefan <--|||Any ideas on what can be done to rectify it?

"Stefan Hoffmann" <stefan.hoffmann@.explido.dewrote in message
news:OFe9nMmOHHA.2232@.TK2MSFTNGP02.phx.gbl...

Quote:

Originally Posted by

hi Neil,
>
Neil wrote:

Quote:

Originally Posted by

>Any ideas as to what's going on or what can be done to rectify this?

Bad WLAN performance, but the network stack is not aware of it. So your
session thinks it is okay, but it's not.
>
>
mfG
--stefan <--

|||hi Neil,

Neil wrote:

Quote:

Originally Posted by

Any ideas on what can be done to rectify it?

Try using a permanent open recordset.
Use filterted recordsets.
Use serverside filters (views).

mfG
--stefan <--|||OK, thanks. I guess I was thinking that, since this system has been in place
for years without these problems; and since these problems just started last
week when the WAN went down for a few hours; that perhaps there was
something on the network end that can be done to rectify it. This has never
been a problem before, so something must have happened to cause it. The
database hasn't changed very much in years.

Thanks,

Neil

"Stefan Hoffmann" <stefan.hoffmann@.explido.dewrote in message
news:e3lZ9rmOHHA.3872@.TK2MSFTNGP06.phx.gbl...

Quote:

Originally Posted by

hi Neil,
>
Neil wrote:

Quote:

Originally Posted by

>Any ideas on what can be done to rectify it?

Try using a permanent open recordset.
Use filterted recordsets.
Use serverside filters (views).
>
>
mfG
--stefan <--

|||"Neil" <nospam@.nospam.netwrote in message
news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earth link.net...

Quote:

Originally Posted by

OK, thanks. I guess I was thinking that, since this system has been in
place for years without these problems; and since these problems just
started last week when the WAN went down for a few hours; that perhaps
there was something on the network end that can be done to rectify it.
This has never been a problem before, so something must have happened to
cause it. The database hasn't changed very much in years.

It is surprising how often only one record is needed for a particular
business function, if it exists, or none, if it does not. Limiting the
number of records retrieved by Query Criteria is a very good way to speed up
client-server performance, and you'll never "lose" several hundred records
on a one-record retrieval. A client-server application which retrieves
hundreds or thousands of records, or more, and then "finds" the one of
interest is not very efficient and effective.

That said, the "fix" is to correct the LAN/WAN problems. I once observed a
company who got a really noticeable improvement when they replaced about 95%
of their network support staff. {:-) or :-(, depending on whether you were
part of the new or the old staff} That said, because a LAN is totally
within control of the network support team, it's much easier to fix than a
WAN, which relies on external providers for some of its services.

Larry Linson
Microsoft Access MVP|||Larry,

I agree with what you wrote 100%. The application was inherited by me after
it was converted to an Access back end from an off-the-shelf product.
There's much that needs to be improved with it. One of the major changes
that we are looking to make is to change the way it works with records in
the way you describe. Bringing over tens of thousands of records is
ridiculous. I was considering giving the user options to work with small,
pre-defined sets of records based on business needs, with the additional
option of a custom set based on search criteria (with the sets being
compiled in the back end, of course, and then brought over). But your note
has made me rethink this. In what situations would the user need anything
*but* a custom set? So I'm rethinking that paradigm, and may just have the
user pull over whatever set of records they need. So thanks for that.

Getting back to the network situation, the problem only seems to manifest
itself in the WAN. The LAN users aren't experiencing this problem. And, as
noted, it only started about a week ago (after many years of the database
and WAN being up and running without this problem) and on the same day that
the WAN went down for several hours. So this tells me that SOMETHING
happened on that day that hasn't yet been rectified. But I know what the
network guy's going to say: everything's working fine now; he doesn't see
any problem with anything. And round and round we go.....

Thanks,

Neil

"Larry Linson" <bouncer@.localhost.notwrote in message
news:iMCrh.3792$E35.2163@.trnddc02...

Quote:

Originally Posted by

>
"Neil" <nospam@.nospam.netwrote in message
news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earth link.net...

Quote:

Originally Posted by

>OK, thanks. I guess I was thinking that, since this system has been in
>place for years without these problems; and since these problems just
>started last week when the WAN went down for a few hours; that perhaps
>there was something on the network end that can be done to rectify it.
>This has never been a problem before, so something must have happened to
>cause it. The database hasn't changed very much in years.

>
It is surprising how often only one record is needed for a particular
business function, if it exists, or none, if it does not. Limiting the
number of records retrieved by Query Criteria is a very good way to speed
up client-server performance, and you'll never "lose" several hundred
records on a one-record retrieval. A client-server application which
retrieves hundreds or thousands of records, or more, and then "finds" the
one of interest is not very efficient and effective.
>
That said, the "fix" is to correct the LAN/WAN problems. I once observed a
company who got a really noticeable improvement when they replaced about
95% of their network support staff. {:-) or :-(, depending on whether you
were part of the new or the old staff} That said, because a LAN is
totally within control of the network support team, it's much easier to
fix than a WAN, which relies on external providers for some of its
services.
>
Larry Linson
Microsoft Access MVP
>
>

|||Neil wrote:

Quote:

Originally Posted by

Getting back to the network situation, the problem only seems to manifest
itself in the WAN. The LAN users aren't experiencing this problem. And, as
noted, it only started about a week ago (after many years of the database
and WAN being up and running without this problem) and on the same day that
the WAN went down for several hours. So this tells me that SOMETHING
happened on that day that hasn't yet been rectified. But I know what the
network guy's going to say: everything's working fine now; he doesn't see
any problem with anything. And round and round we go.....

Is he denying that the WAN outage is responsible for the problem, or is
he just claiming that the WAN outage was an isolated incident and he
doesn't know what caused it and thus he doesn't know how to prevent
future occurrences?

In the former case, you could test the issue by deliberately cutting a
workstation's WAN connection and seeing whether the problem recurs.|||As for what he believes, here's what he wrote:

"It sounds as if it is using cached information and not updating from the
database directly. We are having intermittent issues with the T1s,
but that has been going on for the last few months. Last week the T1s went
down for over two hours this issue was brought to my attention
right after that incident so I am not sure if it is related.

"When I get in this afternoon I'll start sniffing around on the network and
see if there is anything going on at the Network layer.
Later tonight I will reset both the routers and firewalls on both end as
well to see if that helps. I will let them run over the weekend to see what
kind of data we can collect on errors, interface resets etc."

Note that he says the issue was brought to his attention right after the T1s
went down; yet he still isn't sure if the two are related!

Re. testing for the problem, it's hard to do because the problem is very
intermittent. Also, the WAN computers get their data from the remote
location.

Thanks,

Neil

"Ed Murphy" <emurphy42@.socal.rr.comwrote in message
news:45afd262$0$5750$4c368faf@.roadrunner.com...

Quote:

Originally Posted by

Neil wrote:
>

Quote:

Originally Posted by

>Getting back to the network situation, the problem only seems to manifest
>itself in the WAN. The LAN users aren't experiencing this problem. And,
>as noted, it only started about a week ago (after many years of the
>database and WAN being up and running without this problem) and on the
>same day that the WAN went down for several hours. So this tells me that
>SOMETHING happened on that day that hasn't yet been rectified. But I know
>what the network guy's going to say: everything's working fine now; he
>doesn't see any problem with anything. And round and round we go.....

>
Is he denying that the WAN outage is responsible for the problem, or is
he just claiming that the WAN outage was an isolated incident and he
doesn't know what caused it and thus he doesn't know how to prevent
future occurrences?
>
In the former case, you could test the issue by deliberately cutting a
workstation's WAN connection and seeing whether the problem recurs.

Disappearing Records

I am running an Access 2000 MDB against a SQL 7 back end, using ODBC linked
tables over a LAN and a WAN. The system has been operational for years with
relatively few problems.
Recently, WAN users have been reporting several hundred records disappearing
at a time. The records are all sequential, and they're in a table that
contains about 60,000 records. This all started last week at about the same
time (not sure if before or after) that the WAN went down for a couple of
hours for an unknown reason. Since then, every once in a while, a WAN user
will report that several hundred records in a block are just "missing."
Then, an hour or two later, they reappear.
Any ideas as to what's going on or what can be done to rectify this?
Thanks!
Neilhi Neil,
Neil wrote:
> Any ideas as to what's going on or what can be done to rectify this?
Bad WLAN performance, but the network stack is not aware of it. So your
session thinks it is okay, but it's not.
mfG
--> stefan <--|||Any ideas on what can be done to rectify it?
"Stefan Hoffmann" <stefan.hoffmann@.explido.de> wrote in message
news:OFe9nMmOHHA.2232@.TK2MSFTNGP02.phx.gbl...
> hi Neil,
> Neil wrote:
>> Any ideas as to what's going on or what can be done to rectify this?
> Bad WLAN performance, but the network stack is not aware of it. So your
> session thinks it is okay, but it's not.
>
> mfG
> --> stefan <--|||hi Neil,
Neil wrote:
> Any ideas on what can be done to rectify it?
Try using a permanent open recordset.
Use filterted recordsets.
Use serverside filters (views).
mfG
--> stefan <--|||OK, thanks. I guess I was thinking that, since this system has been in place
for years without these problems; and since these problems just started last
week when the WAN went down for a few hours; that perhaps there was
something on the network end that can be done to rectify it. This has never
been a problem before, so something must have happened to cause it. The
database hasn't changed very much in years.
Thanks,
Neil
"Stefan Hoffmann" <stefan.hoffmann@.explido.de> wrote in message
news:e3lZ9rmOHHA.3872@.TK2MSFTNGP06.phx.gbl...
> hi Neil,
> Neil wrote:
>> Any ideas on what can be done to rectify it?
> Try using a permanent open recordset.
> Use filterted recordsets.
> Use serverside filters (views).
>
> mfG
> --> stefan <--|||"Neil" <nospam@.nospam.net> wrote in message
news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earthlink.net...
> OK, thanks. I guess I was thinking that, since this system has been in
> place for years without these problems; and since these problems just
> started last week when the WAN went down for a few hours; that perhaps
> there was something on the network end that can be done to rectify it.
> This has never been a problem before, so something must have happened to
> cause it. The database hasn't changed very much in years.
It is surprising how often only one record is needed for a particular
business function, if it exists, or none, if it does not. Limiting the
number of records retrieved by Query Criteria is a very good way to speed up
client-server performance, and you'll never "lose" several hundred records
on a one-record retrieval. A client-server application which retrieves
hundreds or thousands of records, or more, and then "finds" the one of
interest is not very efficient and effective.
That said, the "fix" is to correct the LAN/WAN problems. I once observed a
company who got a really noticeable improvement when they replaced about 95%
of their network support staff. {:-) or :-(, depending on whether you were
part of the new or the old staff} That said, because a LAN is totally
within control of the network support team, it's much easier to fix than a
WAN, which relies on external providers for some of its services.
Larry Linson
Microsoft Access MVP|||Larry,
I agree with what you wrote 100%. The application was inherited by me after
it was converted to an Access back end from an off-the-shelf product.
There's much that needs to be improved with it. One of the major changes
that we are looking to make is to change the way it works with records in
the way you describe. Bringing over tens of thousands of records is
ridiculous. I was considering giving the user options to work with small,
pre-defined sets of records based on business needs, with the additional
option of a custom set based on search criteria (with the sets being
compiled in the back end, of course, and then brought over). But your note
has made me rethink this. In what situations would the user need anything
*but* a custom set? So I'm rethinking that paradigm, and may just have the
user pull over whatever set of records they need. So thanks for that.
Getting back to the network situation, the problem only seems to manifest
itself in the WAN. The LAN users aren't experiencing this problem. And, as
noted, it only started about a week ago (after many years of the database
and WAN being up and running without this problem) and on the same day that
the WAN went down for several hours. So this tells me that SOMETHING
happened on that day that hasn't yet been rectified. But I know what the
network guy's going to say: everything's working fine now; he doesn't see
any problem with anything. And round and round we go.....
Thanks,
Neil
"Larry Linson" <bouncer@.localhost.not> wrote in message
news:iMCrh.3792$E35.2163@.trnddc02...
> "Neil" <nospam@.nospam.net> wrote in message
> news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earthlink.net...
>> OK, thanks. I guess I was thinking that, since this system has been in
>> place for years without these problems; and since these problems just
>> started last week when the WAN went down for a few hours; that perhaps
>> there was something on the network end that can be done to rectify it.
>> This has never been a problem before, so something must have happened to
>> cause it. The database hasn't changed very much in years.
> It is surprising how often only one record is needed for a particular
> business function, if it exists, or none, if it does not. Limiting the
> number of records retrieved by Query Criteria is a very good way to speed
> up client-server performance, and you'll never "lose" several hundred
> records on a one-record retrieval. A client-server application which
> retrieves hundreds or thousands of records, or more, and then "finds" the
> one of interest is not very efficient and effective.
> That said, the "fix" is to correct the LAN/WAN problems. I once observed a
> company who got a really noticeable improvement when they replaced about
> 95% of their network support staff. {:-) or :-(, depending on whether you
> were part of the new or the old staff} That said, because a LAN is
> totally within control of the network support team, it's much easier to
> fix than a WAN, which relies on external providers for some of its
> services.
> Larry Linson
> Microsoft Access MVP
>|||Neil wrote:
> Getting back to the network situation, the problem only seems to manifest
> itself in the WAN. The LAN users aren't experiencing this problem. And, as
> noted, it only started about a week ago (after many years of the database
> and WAN being up and running without this problem) and on the same day that
> the WAN went down for several hours. So this tells me that SOMETHING
> happened on that day that hasn't yet been rectified. But I know what the
> network guy's going to say: everything's working fine now; he doesn't see
> any problem with anything. And round and round we go.....
Is he denying that the WAN outage is responsible for the problem, or is
he just claiming that the WAN outage was an isolated incident and he
doesn't know what caused it and thus he doesn't know how to prevent
future occurrences?
In the former case, you could test the issue by deliberately cutting a
workstation's WAN connection and seeing whether the problem recurs.|||As for what he believes, here's what he wrote:
"It sounds as if it is using cached information and not updating from the
database directly. We are having intermittent issues with the T1s,
but that has been going on for the last few months. Last week the T1s went
down for over two hours this issue was brought to my attention
right after that incident so I am not sure if it is related.
"When I get in this afternoon I'll start sniffing around on the network and
see if there is anything going on at the Network layer.
Later tonight I will reset both the routers and firewalls on both end as
well to see if that helps. I will let them run over the weekend to see what
kind of data we can collect on errors, interface resets etc."
Note that he says the issue was brought to his attention right after the T1s
went down; yet he still isn't sure if the two are related!
Re. testing for the problem, it's hard to do because the problem is very
intermittent. Also, the WAN computers get their data from the remote
location.
Thanks,
Neil
"Ed Murphy" <emurphy42@.socal.rr.com> wrote in message
news:45afd262$0$5750$4c368faf@.roadrunner.com...
> Neil wrote:
>> Getting back to the network situation, the problem only seems to manifest
>> itself in the WAN. The LAN users aren't experiencing this problem. And,
>> as noted, it only started about a week ago (after many years of the
>> database and WAN being up and running without this problem) and on the
>> same day that the WAN went down for several hours. So this tells me that
>> SOMETHING happened on that day that hasn't yet been rectified. But I know
>> what the network guy's going to say: everything's working fine now; he
>> doesn't see any problem with anything. And round and round we go.....
> Is he denying that the WAN outage is responsible for the problem, or is
> he just claiming that the WAN outage was an isolated incident and he
> doesn't know what caused it and thus he doesn't know how to prevent
> future occurrences?
> In the former case, you could test the issue by deliberately cutting a
> workstation's WAN connection and seeing whether the problem recurs.

Disappearing Records

I am running an Access 2000 MDB against a SQL 7 back end, using ODBC linked
tables over a LAN and a WAN. The system has been operational for years with
relatively few problems.
Recently, WAN users have been reporting several hundred records disappearing
at a time. The records are all sequential, and they're in a table that
contains about 60,000 records. This all started last week at about the same
time (not sure if before or after) that the WAN went down for a couple of
hours for an unknown reason. Since then, every once in a while, a WAN user
will report that several hundred records in a block are just "missing."
Then, an hour or two later, they reappear.
Any ideas as to what's going on or what can be done to rectify this?
Thanks!
Neil
Any ideas on what can be done to rectify it?
"Stefan Hoffmann" <stefan.hoffmann@.explido.de> wrote in message
news:OFe9nMmOHHA.2232@.TK2MSFTNGP02.phx.gbl...
> hi Neil,
> Neil wrote:
> Bad WLAN performance, but the network stack is not aware of it. So your
> session thinks it is okay, but it's not.
>
> mfG
> --> stefan <--
|||OK, thanks. I guess I was thinking that, since this system has been in place
for years without these problems; and since these problems just started last
week when the WAN went down for a few hours; that perhaps there was
something on the network end that can be done to rectify it. This has never
been a problem before, so something must have happened to cause it. The
database hasn't changed very much in years.
Thanks,
Neil
"Stefan Hoffmann" <stefan.hoffmann@.explido.de> wrote in message
news:e3lZ9rmOHHA.3872@.TK2MSFTNGP06.phx.gbl...
> hi Neil,
> Neil wrote:
> Try using a permanent open recordset.
> Use filterted recordsets.
> Use serverside filters (views).
>
> mfG
> --> stefan <--
|||"Neil" <nospam@.nospam.net> wrote in message
news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earth link.net...
> OK, thanks. I guess I was thinking that, since this system has been in
> place for years without these problems; and since these problems just
> started last week when the WAN went down for a few hours; that perhaps
> there was something on the network end that can be done to rectify it.
> This has never been a problem before, so something must have happened to
> cause it. The database hasn't changed very much in years.
It is surprising how often only one record is needed for a particular
business function, if it exists, or none, if it does not. Limiting the
number of records retrieved by Query Criteria is a very good way to speed up
client-server performance, and you'll never "lose" several hundred records
on a one-record retrieval. A client-server application which retrieves
hundreds or thousands of records, or more, and then "finds" the one of
interest is not very efficient and effective.
That said, the "fix" is to correct the LAN/WAN problems. I once observed a
company who got a really noticeable improvement when they replaced about 95%
of their network support staff. {:-) or :-(, depending on whether you were
part of the new or the old staff} That said, because a LAN is totally
within control of the network support team, it's much easier to fix than a
WAN, which relies on external providers for some of its services.
Larry Linson
Microsoft Access MVP
|||Larry,
I agree with what you wrote 100%. The application was inherited by me after
it was converted to an Access back end from an off-the-shelf product.
There's much that needs to be improved with it. One of the major changes
that we are looking to make is to change the way it works with records in
the way you describe. Bringing over tens of thousands of records is
ridiculous. I was considering giving the user options to work with small,
pre-defined sets of records based on business needs, with the additional
option of a custom set based on search criteria (with the sets being
compiled in the back end, of course, and then brought over). But your note
has made me rethink this. In what situations would the user need anything
*but* a custom set? So I'm rethinking that paradigm, and may just have the
user pull over whatever set of records they need. So thanks for that.
Getting back to the network situation, the problem only seems to manifest
itself in the WAN. The LAN users aren't experiencing this problem. And, as
noted, it only started about a week ago (after many years of the database
and WAN being up and running without this problem) and on the same day that
the WAN went down for several hours. So this tells me that SOMETHING
happened on that day that hasn't yet been rectified. But I know what the
network guy's going to say: everything's working fine now; he doesn't see
any problem with anything. And round and round we go.....
Thanks,
Neil
"Larry Linson" <bouncer@.localhost.not> wrote in message
news:iMCrh.3792$E35.2163@.trnddc02...
> "Neil" <nospam@.nospam.net> wrote in message
> news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earth link.net...
> It is surprising how often only one record is needed for a particular
> business function, if it exists, or none, if it does not. Limiting the
> number of records retrieved by Query Criteria is a very good way to speed
> up client-server performance, and you'll never "lose" several hundred
> records on a one-record retrieval. A client-server application which
> retrieves hundreds or thousands of records, or more, and then "finds" the
> one of interest is not very efficient and effective.
> That said, the "fix" is to correct the LAN/WAN problems. I once observed a
> company who got a really noticeable improvement when they replaced about
> 95% of their network support staff. {:-) or :-(, depending on whether you
> were part of the new or the old staff} That said, because a LAN is
> totally within control of the network support team, it's much easier to
> fix than a WAN, which relies on external providers for some of its
> services.
> Larry Linson
> Microsoft Access MVP
>
|||Neil wrote:

> Getting back to the network situation, the problem only seems to manifest
> itself in the WAN. The LAN users aren't experiencing this problem. And, as
> noted, it only started about a week ago (after many years of the database
> and WAN being up and running without this problem) and on the same day that
> the WAN went down for several hours. So this tells me that SOMETHING
> happened on that day that hasn't yet been rectified. But I know what the
> network guy's going to say: everything's working fine now; he doesn't see
> any problem with anything. And round and round we go.....
Is he denying that the WAN outage is responsible for the problem, or is
he just claiming that the WAN outage was an isolated incident and he
doesn't know what caused it and thus he doesn't know how to prevent
future occurrences?
In the former case, you could test the issue by deliberately cutting a
workstation's WAN connection and seeing whether the problem recurs.
|||As for what he believes, here's what he wrote:
"It sounds as if it is using cached information and not updating from the
database directly. We are having intermittent issues with the T1s,
but that has been going on for the last few months. Last week the T1s went
down for over two hours this issue was brought to my attention
right after that incident so I am not sure if it is related.
"When I get in this afternoon I'll start sniffing around on the network and
see if there is anything going on at the Network layer.
Later tonight I will reset both the routers and firewalls on both end as
well to see if that helps. I will let them run over the weekend to see what
kind of data we can collect on errors, interface resets etc."
Note that he says the issue was brought to his attention right after the T1s
went down; yet he still isn't sure if the two are related!
Re. testing for the problem, it's hard to do because the problem is very
intermittent. Also, the WAN computers get their data from the remote
location.
Thanks,
Neil
"Ed Murphy" <emurphy42@.socal.rr.com> wrote in message
news:45afd262$0$5750$4c368faf@.roadrunner.com...
> Neil wrote:
>
> Is he denying that the WAN outage is responsible for the problem, or is
> he just claiming that the WAN outage was an isolated incident and he
> doesn't know what caused it and thus he doesn't know how to prevent
> future occurrences?
> In the former case, you could test the issue by deliberately cutting a
> workstation's WAN connection and seeing whether the problem recurs.

Disappearing Records

I am running an Access 2000 MDB against a SQL 7 back end, using ODBC linked
tables over a LAN and a WAN. The system has been operational for years with
relatively few problems.
Recently, WAN users have been reporting several hundred records disappearing
at a time. The records are all sequential, and they're in a table that
contains about 60,000 records. This all started last week at about the same
time (not sure if before or after) that the WAN went down for a couple of
hours for an unknown reason. Since then, every once in a while, a WAN user
will report that several hundred records in a block are just "missing."
Then, an hour or two later, they reappear.
Any ideas as to what's going on or what can be done to rectify this?
Thanks!
Neilhi Neil,
Neil wrote:
> Any ideas as to what's going on or what can be done to rectify this?
Bad WLAN performance, but the network stack is not aware of it. So your
session thinks it is okay, but it's not.
mfG
--> stefan <--|||Any ideas on what can be done to rectify it?
"Stefan Hoffmann" <stefan.hoffmann@.explido.de> wrote in message
news:OFe9nMmOHHA.2232@.TK2MSFTNGP02.phx.gbl...
> hi Neil,
> Neil wrote:
> Bad WLAN performance, but the network stack is not aware of it. So your
> session thinks it is okay, but it's not.
>
> mfG
> --> stefan <--|||hi Neil,
Neil wrote:
> Any ideas on what can be done to rectify it?
Try using a permanent open recordset.
Use filterted recordsets.
Use serverside filters (views).
mfG
--> stefan <--|||OK, thanks. I guess I was thinking that, since this system has been in place
for years without these problems; and since these problems just started last
week when the WAN went down for a few hours; that perhaps there was
something on the network end that can be done to rectify it. This has never
been a problem before, so something must have happened to cause it. The
database hasn't changed very much in years.
Thanks,
Neil
"Stefan Hoffmann" <stefan.hoffmann@.explido.de> wrote in message
news:e3lZ9rmOHHA.3872@.TK2MSFTNGP06.phx.gbl...
> hi Neil,
> Neil wrote:
> Try using a permanent open recordset.
> Use filterted recordsets.
> Use serverside filters (views).
>
> mfG
> --> stefan <--|||"Neil" <nospam@.nospam.net> wrote in message
news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earthlink.net...
> OK, thanks. I guess I was thinking that, since this system has been in
> place for years without these problems; and since these problems just
> started last week when the WAN went down for a few hours; that perhaps
> there was something on the network end that can be done to rectify it.
> This has never been a problem before, so something must have happened to
> cause it. The database hasn't changed very much in years.
It is surprising how often only one record is needed for a particular
business function, if it exists, or none, if it does not. Limiting the
number of records retrieved by Query Criteria is a very good way to speed up
client-server performance, and you'll never "lose" several hundred records
on a one-record retrieval. A client-server application which retrieves
hundreds or thousands of records, or more, and then "finds" the one of
interest is not very efficient and effective.
That said, the "fix" is to correct the LAN/WAN problems. I once observed a
company who got a really noticeable improvement when they replaced about 95%
of their network support staff. {:-) or :-(, depending on whether you w
ere
part of the new or the old staff} That said, because a LAN is totally
within control of the network support team, it's much easier to fix than a
WAN, which relies on external providers for some of its services.
Larry Linson
Microsoft Access MVP|||Larry,
I agree with what you wrote 100%. The application was inherited by me after
it was converted to an Access back end from an off-the-shelf product.
There's much that needs to be improved with it. One of the major changes
that we are looking to make is to change the way it works with records in
the way you describe. Bringing over tens of thousands of records is
ridiculous. I was considering giving the user options to work with small,
pre-defined sets of records based on business needs, with the additional
option of a custom set based on search criteria (with the sets being
compiled in the back end, of course, and then brought over). But your note
has made me rethink this. In what situations would the user need anything
*but* a custom set? So I'm rethinking that paradigm, and may just have the
user pull over whatever set of records they need. So thanks for that.
Getting back to the network situation, the problem only seems to manifest
itself in the WAN. The LAN users aren't experiencing this problem. And, as
noted, it only started about a week ago (after many years of the database
and WAN being up and running without this problem) and on the same day that
the WAN went down for several hours. So this tells me that SOMETHING
happened on that day that hasn't yet been rectified. But I know what the
network guy's going to say: everything's working fine now; he doesn't see
any problem with anything. And round and round we go.....
Thanks,
Neil
"Larry Linson" <bouncer@.localhost.not> wrote in message
news:iMCrh.3792$E35.2163@.trnddc02...
> "Neil" <nospam@.nospam.net> wrote in message
> news:XNvrh.12389$yx6.3307@.newsread2.news.pas.earthlink.net...
> It is surprising how often only one record is needed for a particular
> business function, if it exists, or none, if it does not. Limiting the
> number of records retrieved by Query Criteria is a very good way to speed
> up client-server performance, and you'll never "lose" several hundred
> records on a one-record retrieval. A client-server application which
> retrieves hundreds or thousands of records, or more, and then "finds" the
> one of interest is not very efficient and effective.
> That said, the "fix" is to correct the LAN/WAN problems. I once observed a
> company who got a really noticeable improvement when they replaced about
> 95% of their network support staff. {:-) or :-(, depending on whether
you
> were part of the new or the old staff} That said, because a LAN is
> totally within control of the network support team, it's much easier to
> fix than a WAN, which relies on external providers for some of its
> services.
> Larry Linson
> Microsoft Access MVP
>|||Neil wrote:

> Getting back to the network situation, the problem only seems to manifest
> itself in the WAN. The LAN users aren't experiencing this problem. And, as
> noted, it only started about a week ago (after many years of the database
> and WAN being up and running without this problem) and on the same day tha
t
> the WAN went down for several hours. So this tells me that SOMETHING
> happened on that day that hasn't yet been rectified. But I know what the
> network guy's going to say: everything's working fine now; he doesn't see
> any problem with anything. And round and round we go.....
Is he denying that the WAN outage is responsible for the problem, or is
he just claiming that the WAN outage was an isolated incident and he
doesn't know what caused it and thus he doesn't know how to prevent
future occurrences?
In the former case, you could test the issue by deliberately cutting a
workstation's WAN connection and seeing whether the problem recurs.|||As for what he believes, here's what he wrote:
"It sounds as if it is using cached information and not updating from the
database directly. We are having intermittent issues with the T1s,
but that has been going on for the last few months. Last week the T1s went
down for over two hours this issue was brought to my attention
right after that incident so I am not sure if it is related.
"When I get in this afternoon I'll start sniffing around on the network and
see if there is anything going on at the Network layer.
Later tonight I will reset both the routers and firewalls on both end as
well to see if that helps. I will let them run over the weekend to see what
kind of data we can collect on errors, interface resets etc."
Note that he says the issue was brought to his attention right after the T1s
went down; yet he still isn't sure if the two are related!
Re. testing for the problem, it's hard to do because the problem is very
intermittent. Also, the WAN computers get their data from the remote
location.
Thanks,
Neil
"Ed Murphy" <emurphy42@.socal.rr.com> wrote in message
news:45afd262$0$5750$4c368faf@.roadrunner
.com...
> Neil wrote:
>
> Is he denying that the WAN outage is responsible for the problem, or is
> he just claiming that the WAN outage was an isolated incident and he
> doesn't know what caused it and thus he doesn't know how to prevent
> future occurrences?
> In the former case, you could test the issue by deliberately cutting a
> workstation's WAN connection and seeing whether the problem recurs.

Disable web connection in Microsoft Document Explorer

How do I disable Internet connectivity in the Microsoft Document Explorer - the help system?

Thanks,

Tom Morris

Use "Try local only, not online" option in Menu->Tools->Option->Online->When loading Help Content

Disable SQL

Hi
I use SPSS for Windows on XP (HE). My system nearly came
to a halt recently, and I noticed SQL.LOG was a
fragmented text file (830 Mb) on C drive. I opened a new
text file and saved it as SQL.LOG in the same location.
This solved my problem, but I don't know how to disable
SQL and I don't know what would happen if I did.
Hope you can help.
VintageRad
It sounds to me like ODBC Tracing is enabled on this computer. You can turn
it off from Control Panel. In my case, running on Windows XP, it's Control
Panel/Administrative Tools/Data Sources (ODBC), and the Tracing tab. After
you've turned it off, you can delete that file.
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"VintageRad" <vintage_rad@.msn.com> wrote in message
news:680d01c493eb$adc65370$a601280a@.phx.gbl...
> Hi
> I use SPSS for Windows on XP (HE). My system nearly came
> to a halt recently, and I noticed SQL.LOG was a
> fragmented text file (830 Mb) on C drive. I opened a new
> text file and saved it as SQL.LOG in the same location.
> This solved my problem, but I don't know how to disable
> SQL and I don't know what would happen if I did.
> Hope you can help.
> VintageRad
|||*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Stephen
That advice was very helpful. The SQL.LOG txt file is no longer filling
up.
VintageRad
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!

disable log on user login events

my server is have user login (by services) 5~8 times per second, and all these events are logged in sql log and system application events log.
will this cause problem to the server? as each entry will cause a open/close action.
if yes, how can i disable them?Originally posted by timothymo
my server is have user login (by services) 5~8 times per second, and all these events are logged in sql log and system application events log.

will this cause problem to the server? as each entry will cause a open/close action.

if yes, how can i disable them?

Hi.... :)

Open / Close of DB file is not an issue its an configuration setting in Select DB Right click /Property / Options tab - Auto Close on-Off. This is to release the resource while DB is not in use. When any user use this DB the DB file will be opened.

If you don't want to use the login to be logged disable Server property / Security - Audit level (None or failure)

Cheers ,

Shaji