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 parameter values

I have an ASP.NET application with a page which has a Reportviewer control
linked to a Reporting Services report on a Remote Server. I pass parameters
into it OK including the name of the database which is then referenced by a
dynamic connection string. The database is the first parameter. Other
parameters have dropdown lists based on datasets using the dynamic connection
string.
All of this works fine, but...
When I hide some of the parameters, because I know what value is required,
the value is not acceoted, nor does the report use the default value. It is
as though hiding the parameter prevents the list of available values being
requeried; consequently the passed in value is ignored as it does not match
an available value!
Can anyone help please?
Thanks
GeorgeGeorge,
I assume you are setting the Visible property of some web control that
holds the value of your report parameter. You should set the Visibility
Style of the control to 'hidden' so that it still gets rendered into the web
form but is not 'seen' in the web browser. This way the controls value is
still within the form and viewstate when the form is posted back.
Hope I made the correct assumption and this helps.
thx
-jsh
"George Davies" wrote:
> I have an ASP.NET application with a page which has a Reportviewer control
> linked to a Reporting Services report on a Remote Server. I pass parameters
> into it OK including the name of the database which is then referenced by a
> dynamic connection string. The database is the first parameter. Other
> parameters have dropdown lists based on datasets using the dynamic connection
> string.
> All of this works fine, but...
> When I hide some of the parameters, because I know what value is required,
> the value is not acceoted, nor does the report use the default value. It is
> as though hiding the parameter prevents the list of available values being
> requeried; consequently the passed in value is ignored as it does not match
> an available value!
> Can anyone help please?
> Thanks
> George|||Thanks jsh for replying so promptly
I'm not sure I've explained the problem correctly, as I could not find the
Visibility Style for the control as you suggested. I am using RS2005 and
ASP.NET 1.1 with a ReportViewer control linked to a deployed remote report.
But I think you may be on to something as the problem does not arise when
designing the report, nor in Report Manager, only when I run it from within
the ASP ReportViewer control as a Remote Report.
The parameter is passed into the Reporting Services report OK, but when the
Report Server processes the parameters it first takes the name of the
database as the first parameter, then it recognises that there are cascading
parameters because the dropdown lists require data from tables which have
been queried using the dynamic connection string. At this point it seems to
assume that because it is going to refresh the dropdown lists that it can no
longer rely on the selections supplied in the other parameters and scrubs
them i.e. it insists that the user rekey each of the parameter values
wherever the dropdown lists use the dynamic connection string.
This causes two problems:
1 When I want a parameter value hidden, it is impossible to set it and the
report fails with e.g. "Parameter zzz does not have a value". I could get
round this by using two parameters for each value, one for when I want to
force the parameter to be a certain value and hide it with no associated
dropdown list, and one for when I want to show it and ask the user to pick
from a list. Messy, but I could get the report SQL to test for either of the
values in the two parameters. But this still leaves problem number 2...
2 When cascading parameters are used, each time the user picks a value, it
postbacks to the server. This is not very clever of Reporting Services. It
should post back when the value for a parameter is changed where that
parameter is used by other parameters, not when a parameter changes which
uses the value from another parameter.
The long and short of it is that with eight parameters, the selection of
report options is excruciatingly slow and won't be acceptable to my users.
If you or anyone else can shed any light on this problem, I would be really
grateful.
Thanks again and best wishes
George
"jsh02_nova@.hotmail.com" wrote:
> George,
> I assume you are setting the Visible property of some web control that
> holds the value of your report parameter. You should set the Visibility
> Style of the control to 'hidden' so that it still gets rendered into the web
> form but is not 'seen' in the web browser. This way the controls value is
> still within the form and viewstate when the form is posted back.
> Hope I made the correct assumption and this helps.
> thx
> -jsh
> "George Davies" wrote:
> > I have an ASP.NET application with a page which has a Reportviewer control
> > linked to a Reporting Services report on a Remote Server. I pass parameters
> > into it OK including the name of the database which is then referenced by a
> > dynamic connection string. The database is the first parameter. Other
> > parameters have dropdown lists based on datasets using the dynamic connection
> > string.
> >
> > All of this works fine, but...
> >
> > When I hide some of the parameters, because I know what value is required,
> > the value is not acceoted, nor does the report use the default value. It is
> > as though hiding the parameter prevents the list of available values being
> > requeried; consequently the passed in value is ignored as it does not match
> > an available value!
> >
> > Can anyone help please?
> >
> > Thanks
> >
> > George

Disappearing Linked Server Stored Procedures

When I create a stored procedure like the one below and save it,
everything seems fine. But when I close Enterprise Manager and
re-open it, the stored procedure is gone.

Any ideas?

SET ANSI_DEFAULTS ON
GO
CREATE PROCEDURE [dbo].[sp_Test] AS
SELECT * FROM OPENQUERY(LINKEDSERVER, 'SELECT V.VENDOR_ID,
V.VENDOR_NAME FROM VENDOR V')
GO

Ted"Ted Calhoon" <tedcalhoon@.hotmail.com> wrote in message
news:fc57c4d8.0312121455.1e0677d8@.posting.google.c om...
> When I create a stored procedure like the one below and save it,
> everything seems fine. But when I close Enterprise Manager and
> re-open it, the stored procedure is gone.
> Any ideas?
>
> SET ANSI_DEFAULTS ON
> GO
> CREATE PROCEDURE [dbo].[sp_Test] AS
> SELECT * FROM OPENQUERY(LINKEDSERVER, 'SELECT V.VENDOR_ID,
> V.VENDOR_NAME FROM VENDOR V')
> GO
>
> Ted

If you put only the CREATE PROCEDURE statement into the create procedure
dialogue, it will work:

CREATE PROCEDURE [dbo].[sp_Test] AS
SELECT * FROM OPENQUERY(LINKEDSERVER, 'SELECT V.VENDOR_ID,
V.VENDOR_NAME FROM VENDOR V')

Presumably, this is a 'feature' in EM, which seems to have a number of
quirks. If you need full control over the CREATE PROC statement, you should
execute it in Query Analyzer instead, which is probably a better practice in
general.

Also, don't use sp_ as a procedure name prefix, that's reserved for system
stored procedures.

Simon|||Thanks, Simon. I will take your advice and:

1. Use Query Analyzer to create stored procedures
2. Avoid using sp_ when naming my stored procedures

Ted

Disabling/enabling of trigger & distributed transaction

I've 2 Windows 2000 server running each own instance of SQL2000. I've setup
both linked servers @. both end.
At server A, it'll call a sp in server B, whereby this sp will update server
B tables based on server A's data. And the server A table A will trigger
back to server B.
However due to some business logic and distributed transaction don't allow a
loopback operation, is there any method the trigger can be bypassed?
I can't drop this trigger as it need to be maintained when other process
access this table.
My question is, can a disable/enable trigger be issued in this sp?
What if another process updating this table at the same time and need the
trigger to be enabled? Will this process be queued after this completion of
sp?
Please advice on how feasible can trigger be controlled from firing..
Server_A call ServerB.sp
|
V
store procedure @. serverB
begin transaction
-- disable trigger
insert into serverB.dbB.dbo.tableB
select * from serverA.dbA.dbo.tableA where key=X
commit transaction
-- enable trigger
|
V
serverB.dbB.dbo.tableB trigger back to serverA
if record not found in serverA
insert into serverA
else
update into server A
Thanks in advance
KristeHi
You can do an ALTER TABLE with the ENABLE/DISABLE TRIGGER, but, the
disabling is for all connections.
The only way you could do this is to have the trigger look up in a table
what connections it can fire for. Not elegant, but might be workable.
Regards
Mike
"Kriste L" wrote:

> I've 2 Windows 2000 server running each own instance of SQL2000. I've setu
p
> both linked servers @. both end.
> At server A, it'll call a sp in server B, whereby this sp will update serv
er
> B tables based on server A's data. And the server A table A will trigger
> back to server B.
> However due to some business logic and distributed transaction don't allow
a
> loopback operation, is there any method the trigger can be bypassed?
> I can't drop this trigger as it need to be maintained when other process
> access this table.
> My question is, can a disable/enable trigger be issued in this sp?
> What if another process updating this table at the same time and need the
> trigger to be enabled? Will this process be queued after this completion o
f
> sp?
> Please advice on how feasible can trigger be controlled from firing..
> Server_A call ServerB.sp
> |
> V
> store procedure @. serverB
> begin transaction
> -- disable trigger
> insert into serverB.dbB.dbo.tableB
> select * from serverA.dbA.dbo.tableA where key=X
> commit transaction
> -- enable trigger
>
> |
> V
> serverB.dbB.dbo.tableB trigger back to serverA
> if record not found in serverA
> insert into serverA
> else
> update into server A
>
> Thanks in advance
> Kriste
>
>