I'm having a problem with text boxes disappearing when a report is exported
to PDF. Everything appears fine in the designer and in Report Manager, even
when exporting to Excel, but when the report is exported to PDF, a couple of
text boxes (one being a label above a table, and the other, next to the
label, shows a company name returned from a stored procedure) appear on some
pages of the report, but not on others. There is another text box label, and
another text box beside it which returns a company's branch name...this is
directly under the company name...this appears OK on the PDF. There are no
null/blank company names being returned in the dataset.
I created a test copy of the same report (from scratch) and exported it to
PDF. This time, the company name text boxes that were missing before appeared
OK, but went missing on other pages which were previously fine.
I've tried putting the text boxes into a rectangle, even a list, but to no
avail. I can't really see any pattern to the problem...the two copies of the
report are returning exactly the same data, but the company name text boxes
randomly disappear.
Can anyone shed some light on this problem? Is it a bug?
Thanks in advance.
--
Jadranka Krapic
DBA
Stargate Technologies
(www.stargatetech.com.au)Jadranka wrote:
<snip>
> I've tried putting the text boxes into a rectangle, even a list, but
> to no avail. I can't really see any pattern to the problem...the two
> copies of the report are returning exactly the same data, but the
> company name text boxes randomly disappear.
> Can anyone shed some light on this problem? Is it a bug?
> Thanks in advance.
The "export engines" as they are often called are black boxes and yes,
I think you are seeing evidence that the PDF export engine has defects.
I have "solved" similar problems through hours of fiddling redesign.
The PDF engine has problems with the widths of things, with things next
to each other horizontally, and don't ever overlap ReportItems by so
much as a single twip or you'll regret it.
Interesting that for you also there is no obvious consistent pattern to
what works and what does not, my experience precisely.
I have moaned and groaned about these issues for a week or two without
getting any meaningful answers from Microsoft support, sometimes
without getting any answers at all.
One hopes that SP2 will address these genuine showstopper issues. It's
one thing for members of an IT organization to put up with a
not-done-yet product like Microsoft SQL Reporting Services, quite
another for business users: they WON'T put up with it. They won't buy
solutions based on it. They will renege on deals already made because
of it. They are uninterested in WHY I can't do for them what needs
doing in a way that is useful to them, all they care about is that I
didn't do it as I said I would.
Under the gun but smiling, smiling, I am
Highly Obscure|||I can most definately relate to your experiences! If I weren't smiling
through it all, I reckon I'd be a basket-case!!
Speaking of smiling, the latest installment of this saga had me and the
senior DBA laughing...
Originally, the company name text box label had a location of 0cm, 0cm on
the list that it was sitting on. Thought I'd nudge everything down a little,
just so it wasn't at the very top of the list control. Exported it to
PDF...HEY PRESTO! A perfect PDF report! Go figure.
Still doesn't explain why previously some text box controls were appearing
on some pages and not on others, but I (and the customer) are happy with what
we've got now.
Jadranka.
"HighlyObscure" wrote:
> Jadranka wrote:
> <snip>
> >
> > I've tried putting the text boxes into a rectangle, even a list, but
> > to no avail. I can't really see any pattern to the problem...the two
> > copies of the report are returning exactly the same data, but the
> > company name text boxes randomly disappear.
> >
> > Can anyone shed some light on this problem? Is it a bug?
> >
> > Thanks in advance.
> The "export engines" as they are often called are black boxes and yes,
> I think you are seeing evidence that the PDF export engine has defects.
> I have "solved" similar problems through hours of fiddling redesign.
> The PDF engine has problems with the widths of things, with things next
> to each other horizontally, and don't ever overlap ReportItems by so
> much as a single twip or you'll regret it.
> Interesting that for you also there is no obvious consistent pattern to
> what works and what does not, my experience precisely.
> I have moaned and groaned about these issues for a week or two without
> getting any meaningful answers from Microsoft support, sometimes
> without getting any answers at all.
> One hopes that SP2 will address these genuine showstopper issues. It's
> one thing for members of an IT organization to put up with a
> not-done-yet product like Microsoft SQL Reporting Services, quite
> another for business users: they WON'T put up with it. They won't buy
> solutions based on it. They will renege on deals already made because
> of it. They are uninterested in WHY I can't do for them what needs
> doing in a way that is useful to them, all they care about is that I
> didn't do it as I said I would.
> Under the gun but smiling, smiling, I am
> Highly Obscure
>
2012年3月8日星期四
disappearing SQL reg. properties
When I try to see the properties of my sql registration it pops up and disappears immediately. Any one seen this before?
-KevinCheck under SQL error log for any kind of information.
And also try to lookup properties for that server from other machine.|||yes, the error log gives me some bogus message about recongigure (with override)
we tried it from another machine witht eh same error.|||WHat is the OS and SP level? (service pack)
And also for SQL server SP Level?
Try to post the brief message from error log.|||Windows 2000 sp3
sql 2000 standard edition sp3
Configuration option 'show advanced options' changed from 1 to 1. Run the RECONFIGURE statement to install..
Error: 15457, Severity: 0, State: 1|||This error usually means that someone or something run sp_configure
without the RECONFIGURE statement. And this occurs if you change the property through enterprise manager.
In this case it looks like the 'show advanced options' was already set to 1 and something then tried to change it to 1 again. SQL Server then noted that the RECONFIGURE option was not used and therefore complained.|||that's why i said it was a bogus error.
ie. someone tried to change 1 to 1.
any other ideas?|||Is this behaviour is same when you tried from other machine?|||yes.
-k|||Then its better to reinstall SQL server, first uninstall and remove referenced registry keys for SQL server - reboot the box and reinstall freshly.
HTH|||Do you mean go into regedit to do this:
"remove referenced registry keys "
Won't the unistall do this for me. If not, what's the harm in leaving them there during the re-install.|||Its better to remove registry keys, to have clean install.
-KevinCheck under SQL error log for any kind of information.
And also try to lookup properties for that server from other machine.|||yes, the error log gives me some bogus message about recongigure (with override)
we tried it from another machine witht eh same error.|||WHat is the OS and SP level? (service pack)
And also for SQL server SP Level?
Try to post the brief message from error log.|||Windows 2000 sp3
sql 2000 standard edition sp3
Configuration option 'show advanced options' changed from 1 to 1. Run the RECONFIGURE statement to install..
Error: 15457, Severity: 0, State: 1|||This error usually means that someone or something run sp_configure
without the RECONFIGURE statement. And this occurs if you change the property through enterprise manager.
In this case it looks like the 'show advanced options' was already set to 1 and something then tried to change it to 1 again. SQL Server then noted that the RECONFIGURE option was not used and therefore complained.|||that's why i said it was a bogus error.
ie. someone tried to change 1 to 1.
any other ideas?|||Is this behaviour is same when you tried from other machine?|||yes.
-k|||Then its better to reinstall SQL server, first uninstall and remove referenced registry keys for SQL server - reboot the box and reinstall freshly.
HTH|||Do you mean go into regedit to do this:
"remove referenced registry keys "
Won't the unistall do this for me. If not, what's the harm in leaving them there during the re-install.|||Its better to remove registry keys, to have clean install.
Disappearing SQL EM registrations
I'm having problems with all of my registered servers in
SQL Server 2000 EM disappear. The 'framework' is still
in place, ie. 'Microsoft SQL Servers | SQL 2K |
Production, etc.', but the servers are no longer
registered.
I have both SQL 7.0 and 2K servers registered in SQL 2K
EM, both of which are disappearing. I've had this
problem occur before and I created a .REG file
on 'HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
Server\80\Tools\SQLEW\Registered Servers X'. I
tried "executing" the file, but the servers didn't re-
register.
It appears to happen whenever I change my Windows /
Novell password after the password has expired. I
changed my password when I got into work this morning (it
had expired) and all of my registered servers had
disappeared. I then registered one server and had our
security folks reset my password and force me to reset
it. I changed my password and re-logged in and the
server was still registered, hence my hypothesis that
this problem only occurs after the password has expired.
I've had at least two other people I work with experience
the same problem, and we're all logging into Windows and
Novell.
Any suggestions would be appreciated!! I'm getting kind
of tired of re-registering 70+ SQL Servers every time my
password changes.
Thanks in advance,
Mike Stuart - mstuart@.gates.com| I'm having problems with all of my registered servers in
| SQL Server 2000 EM disappear. The 'framework' is still
| in place, ie. 'Microsoft SQL Servers | SQL 2K |
| Production, etc.', but the servers are no longer
| registered.
|
| I have both SQL 7.0 and 2K servers registered in SQL 2K
| EM, both of which are disappearing. I've had this
| problem occur before and I created a .REG file
| on 'HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
| Server\80\Tools\SQLEW\Registered Servers X'. I
| tried "executing" the file, but the servers didn't re-
| register.
|
| It appears to happen whenever I change my Windows /
| Novell password after the password has expired. I
| changed my password when I got into work this morning (it
| had expired) and all of my registered servers had
| disappeared. I then registered one server and had our
| security folks reset my password and force me to reset
| it. I changed my password and re-logged in and the
| server was still registered, hence my hypothesis that
| this problem only occurs after the password has expired.
|
| I've had at least two other people I work with experience
| the same problem, and we're all logging into Windows and
| Novell.
|
| Any suggestions would be appreciated!! I'm getting kind
| of tired of re-registering 70+ SQL Servers every time my
| password changes.
|
| Thanks in advance,
|
| Mike Stuart - mstuart@.gates.com
--
Hi Mike,
You problem could be related to:
FIX: Registered Remote Servers Disappear from SQL Enterprise Manager in
Windows XP When Non-Domain User Password is Changed
http://support.microsoft.com/?id=323280
Hope this helps,
--
Eric Cárdenas
SQL Server support|||>--Original Message--
>| I'm having problems with all of my registered servers in >| SQL Server 2000 EM disappear. The 'framework' is still >| in place, ie. 'Microsoft SQL Servers | SQL 2K | >| Production, etc.', but the servers are no longer >| registered.
>| >| I have both SQL 7.0 and 2K servers registered in SQL 2K >| EM, both of which are disappearing. I've had this >| problem occur before and I created a .REG file >| on 'HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL >| Server\80\Tools\SQLEW\Registered Servers X'. I >| tried "executing" the file, but the servers didn't re-
>| register.
>| >| It appears to happen whenever I change my Windows / >| Novell password after the password has expired. I >| changed my password when I got into work this morning (it >| had expired) and all of my registered servers had >| disappeared. I then registered one server and had our >| security folks reset my password and force me to reset >| it. I changed my password and re-logged in and the >| server was still registered, hence my hypothesis that >| this problem only occurs after the password has expired.
>| >| I've had at least two other people I work with experience >| the same problem, and we're all logging into Windows and >| Novell.
>| >| Any suggestions would be appreciated!! I'm getting kind >| of tired of re-registering 70+ SQL Servers every time my >| password changes.
>| >| Thanks in advance,
>| >| Mike Stuart - mstuart@.gates.com
>--
>Hi Mike,
>You problem could be related to:
>FIX: Registered Remote Servers Disappear from SQL Enterprise Manager in >Windows XP When Non-Domain User Password is Changed
>http://support.microsoft.com/?id=3D323280
>Hope this helps,
>--
>Eric C=E1rdenas
>SQL Server support
>.
>
I already had SP3 installed. I make the registry hack and expired my password, then changed my password. The server registrations were still there!!
Thanks for the input / help.
Mike
SQL Server 2000 EM disappear. The 'framework' is still
in place, ie. 'Microsoft SQL Servers | SQL 2K |
Production, etc.', but the servers are no longer
registered.
I have both SQL 7.0 and 2K servers registered in SQL 2K
EM, both of which are disappearing. I've had this
problem occur before and I created a .REG file
on 'HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
Server\80\Tools\SQLEW\Registered Servers X'. I
tried "executing" the file, but the servers didn't re-
register.
It appears to happen whenever I change my Windows /
Novell password after the password has expired. I
changed my password when I got into work this morning (it
had expired) and all of my registered servers had
disappeared. I then registered one server and had our
security folks reset my password and force me to reset
it. I changed my password and re-logged in and the
server was still registered, hence my hypothesis that
this problem only occurs after the password has expired.
I've had at least two other people I work with experience
the same problem, and we're all logging into Windows and
Novell.
Any suggestions would be appreciated!! I'm getting kind
of tired of re-registering 70+ SQL Servers every time my
password changes.
Thanks in advance,
Mike Stuart - mstuart@.gates.com| I'm having problems with all of my registered servers in
| SQL Server 2000 EM disappear. The 'framework' is still
| in place, ie. 'Microsoft SQL Servers | SQL 2K |
| Production, etc.', but the servers are no longer
| registered.
|
| I have both SQL 7.0 and 2K servers registered in SQL 2K
| EM, both of which are disappearing. I've had this
| problem occur before and I created a .REG file
| on 'HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
| Server\80\Tools\SQLEW\Registered Servers X'. I
| tried "executing" the file, but the servers didn't re-
| register.
|
| It appears to happen whenever I change my Windows /
| Novell password after the password has expired. I
| changed my password when I got into work this morning (it
| had expired) and all of my registered servers had
| disappeared. I then registered one server and had our
| security folks reset my password and force me to reset
| it. I changed my password and re-logged in and the
| server was still registered, hence my hypothesis that
| this problem only occurs after the password has expired.
|
| I've had at least two other people I work with experience
| the same problem, and we're all logging into Windows and
| Novell.
|
| Any suggestions would be appreciated!! I'm getting kind
| of tired of re-registering 70+ SQL Servers every time my
| password changes.
|
| Thanks in advance,
|
| Mike Stuart - mstuart@.gates.com
--
Hi Mike,
You problem could be related to:
FIX: Registered Remote Servers Disappear from SQL Enterprise Manager in
Windows XP When Non-Domain User Password is Changed
http://support.microsoft.com/?id=323280
Hope this helps,
--
Eric Cárdenas
SQL Server support|||>--Original Message--
>| I'm having problems with all of my registered servers in >| SQL Server 2000 EM disappear. The 'framework' is still >| in place, ie. 'Microsoft SQL Servers | SQL 2K | >| Production, etc.', but the servers are no longer >| registered.
>| >| I have both SQL 7.0 and 2K servers registered in SQL 2K >| EM, both of which are disappearing. I've had this >| problem occur before and I created a .REG file >| on 'HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL >| Server\80\Tools\SQLEW\Registered Servers X'. I >| tried "executing" the file, but the servers didn't re-
>| register.
>| >| It appears to happen whenever I change my Windows / >| Novell password after the password has expired. I >| changed my password when I got into work this morning (it >| had expired) and all of my registered servers had >| disappeared. I then registered one server and had our >| security folks reset my password and force me to reset >| it. I changed my password and re-logged in and the >| server was still registered, hence my hypothesis that >| this problem only occurs after the password has expired.
>| >| I've had at least two other people I work with experience >| the same problem, and we're all logging into Windows and >| Novell.
>| >| Any suggestions would be appreciated!! I'm getting kind >| of tired of re-registering 70+ SQL Servers every time my >| password changes.
>| >| Thanks in advance,
>| >| Mike Stuart - mstuart@.gates.com
>--
>Hi Mike,
>You problem could be related to:
>FIX: Registered Remote Servers Disappear from SQL Enterprise Manager in >Windows XP When Non-Domain User Password is Changed
>http://support.microsoft.com/?id=3D323280
>Hope this helps,
>--
>Eric C=E1rdenas
>SQL Server support
>.
>
I already had SP3 installed. I make the registry hack and expired my password, then changed my password. The server registrations were still there!!
Thanks for the input / help.
Mike
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.
Bad WLAN performance, but the network stack is not aware of it. So your
session thinks it is okay, but it's not.
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,
Try using a permanent open recordset.
Use filterted recordsets.
Use serverside filters (views).
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...
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.
>
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:
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?
>
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.
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.
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.
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.
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.
Disappearing printer icon
I am finding that sometimes the RS web page displays a printer icon between
the refresh and help icons. This icon brings up a standard print dialog (when
the icon is there) which allows users to print to any of the printers
installed on their local system. It is definitely different than the printer
button on the browser. Reports print as though they were scheduled instead of
just rendered out of IE.
My question is, does anyone know why the icon only shows up on some
reporting services installations? It appears to be RS installation specific.
I get it when I connect to my local RS but when I connect to one on a 2000
server I do not.
TIA,
JimThe print icon was new in Service Pack 2. Is it possible that the server
hasn't had the upgrade?
"JimH" wrote:
> I am finding that sometimes the RS web page displays a printer icon between
> the refresh and help icons. This icon brings up a standard print dialog (when
> the icon is there) which allows users to print to any of the printers
> installed on their local system. It is definitely different than the printer
> button on the browser. Reports print as though they were scheduled instead of
> just rendered out of IE.
> My question is, does anyone know why the icon only shows up on some
> reporting services installations? It appears to be RS installation specific.
> I get it when I connect to my local RS but when I connect to one on a 2000
> server I do not.
> TIA,
> Jim
the refresh and help icons. This icon brings up a standard print dialog (when
the icon is there) which allows users to print to any of the printers
installed on their local system. It is definitely different than the printer
button on the browser. Reports print as though they were scheduled instead of
just rendered out of IE.
My question is, does anyone know why the icon only shows up on some
reporting services installations? It appears to be RS installation specific.
I get it when I connect to my local RS but when I connect to one on a 2000
server I do not.
TIA,
JimThe print icon was new in Service Pack 2. Is it possible that the server
hasn't had the upgrade?
"JimH" wrote:
> I am finding that sometimes the RS web page displays a printer icon between
> the refresh and help icons. This icon brings up a standard print dialog (when
> the icon is there) which allows users to print to any of the printers
> installed on their local system. It is definitely different than the printer
> button on the browser. Reports print as though they were scheduled instead of
> just rendered out of IE.
> My question is, does anyone know why the icon only shows up on some
> reporting services installations? It appears to be RS installation specific.
> I get it when I connect to my local RS but when I connect to one on a 2000
> server I do not.
> TIA,
> Jim
Disappearing Precedence Constraints
Has anyone seen precedence constraints disappear in a package after closing and opening again? In this case, it's not package-wide. Only constraints inside one Foreach Loop container disappeared. Any idea what causes this to happen?
p.s: Yes, I did Save All. Most of these contraints were saved in the package for more than a week anyway.
I have not seen that. Is your package under any source control software? is that the case compare it against previous versions. A similar issue has been reported for many of us; but the problem was inside the Dataflow (when using VSS as source control)though....
|||Hi M. Glenn,
Yep, I've seen it too.
I've seen this and other strange behavior when my Visual Studio environment has been running for days on end (it happens...). My solution is to shut it down and restart the environment. Sometimes the metadata for the objects remains out of sync and the only way to get it back is to either copy it and paste it into a new package or recreate it.
Hope this helps,
Andy
|||Thanks for the quick replies. "...Visual Studio environment...running for days on end": Yeah that's me alright. We're not using any source control utilities, but I was in the habit of leaving VS open for days while working on projects. Not any more. I save frequently, but obviously that's not enough.
I could see and edit the constraints in Package Explorer, and tasks that allow only one connection would correctly return an error if I tried to add another constraint, but they were invisible in Control Flow designer. Closing and restarting the project and/or VS didn't help. Selecting all tasks in the container and dragging them outside the container made the connecters visible again. Then just drag everything back and all is well. Thanks for the tip.
BTW, I'm using VS 2005 Pro--installed after SS05/BIDS. I wonder if those using BIDS without a full VS 2005 install are experiencing this issue. Actually, I’m impressed with how stable SS05 and VS05 are--especially considering how much more complex and feature-filled these products are compared to their predecessors.
|||
M.Glenn wrote:
BTW, I'm using VS 2005 Pro--installed after SS05/BIDS. I wonder if those using BIDS without a full VS 2005 install are experiencing this issue. Actually, I’m impressed with how stable SS05 and VS05 are--especially considering how much more complex and feature-filled these products are compared to their predecessors.
Oh my word. A realist!
Thanks M Glenn. You've restored my faith in the community following some particularly galling diatribes of late!
|||Jamie, those guys must not realize how much progress these products have made in terms of functionality, stability, performance and ease-of-use features (although overall complexity is an unavoidable companion of added functionality). Add to this a world-class customer feedback/support infrastructure (including newsgroups like this one). We all have complaints about Microsoft, but that shouldn't completely blind someone to what's been accomplished here.
The SS and VS "2005" releases are nothing short of amazing. And whoever thought of selling SS05 Developer Edition for $50 is a genius. A year ago I couldn't even get our CIO to spring for that. Ironically, there are so many compelling reasons to upgrade it created a problem of how to fit it all in an executive summary. But DBA's and developers could recognize something special early on. I shelled out $50 from my own pocket and got wowed right off the bat just watching the install routine! Before long I was hounding the CIO without mercy. He eventually gave in when some funds came available.
Recently, I automated report creation, delivery and notification to 40+ healthcare providers with an SSIS package so simple it would make folks who hang out here yawn. But it made me and the CIO look like geniuses. That's what I call progress!
Hi M.Glenn,
Cool! I have to agree with Jamie - it's nice to read about someone's successes with the product.
The forum is similar to a doctor's office - no one shows up and says "Hi folks, everything's fine! See ya!" They usually pop in when something bad is happening or about to happen.
Thanks,
Andy
The forum is similar to a doctor's office - no one shows up and says "Hi folks, everything's fine! See ya!" They usually pop in when something bad is happening or about to happen.
Good analogy. Helps keep the complaints in perspective.
Disappearing point labels
I have deployed a number of reports with bar charts. Most of these bar
charts have numeric point labels. On some charts the upper most and lowest
bars do not display the point labels in preview or report manager. I have
experimented with font size and style, point label position as well as chart
size but I cannot seem to find a consistant solution.
Appreciate any help with this problem.This is a known issue in the chart control and we will look into providing a
fix in a future release.
Current workaround: Turn on margins for the x-axis (which is shown as
vertical axis in bar charts) and the labels will work consistently.
As you have noticed resizing the entire chart or using different font sizes
is not reliable. You may also try turning on 3D mode.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"O8" <andrew.stokes@.vodafone.net> wrote in message
news:usaRaTKpEHA.3848@.tk2msftngp13.phx.gbl...
> I have deployed a number of reports with bar charts. Most of these bar
> charts have numeric point labels. On some charts the upper most and lowest
> bars do not display the point labels in preview or report manager. I have
> experimented with font size and style, point label position as well as
chart
> size but I cannot seem to find a consistant solution.
>
> Appreciate any help with this problem.
>
>
charts have numeric point labels. On some charts the upper most and lowest
bars do not display the point labels in preview or report manager. I have
experimented with font size and style, point label position as well as chart
size but I cannot seem to find a consistant solution.
Appreciate any help with this problem.This is a known issue in the chart control and we will look into providing a
fix in a future release.
Current workaround: Turn on margins for the x-axis (which is shown as
vertical axis in bar charts) and the labels will work consistently.
As you have noticed resizing the entire chart or using different font sizes
is not reliable. You may also try turning on 3D mode.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"O8" <andrew.stokes@.vodafone.net> wrote in message
news:usaRaTKpEHA.3848@.tk2msftngp13.phx.gbl...
> I have deployed a number of reports with bar charts. Most of these bar
> charts have numeric point labels. On some charts the upper most and lowest
> bars do not display the point labels in preview or report manager. I have
> experimented with font size and style, point label position as well as
chart
> size but I cannot seem to find a consistant solution.
>
> Appreciate any help with this problem.
>
>
Disappearing Parameterised Filters and Filter Joins in Publication Properties page of replicatio
Hi,
We have an issue with our replication configuration when viewed through replication monitor. Parameterised Filters and joined filters don't appear in the gui. However, when we script the publication all the filters are present.
This issue only seems to occur when we have a remote distributor.
I should also point out that we have a merge push topology that uses a custom RMO synchronisation component on a separate server to either the publisher or the distributor. Also all the databases in the topology are called the same name. This has caused us other issues relating to this topology in particular so I raise it here as well although I don't expect it to be the case in this instance.
Any help would be greatly appreciated in clarifying this matter.
To get better response, can you submit this bug/issue to http://connect.microsoft.com? We can track it better there, thanks!Disappearing Parameterised Filters and Filter Joins in Publication Properties page of replic
Hi,
We have an issue with our replication configuration when viewed through replication monitor. Parameterised Filters and joined filters don't appear in the gui. However, when we script the publication all the filters are present.
This issue only seems to occur when we have a remote distributor.
I should also point out that we have a merge push topology that uses a custom RMO synchronisation component on a separate server to either the publisher or the distributor. Also all the databases in the topology are called the same name. This has caused us other issues relating to this topology in particular so I raise it here as well although I don't expect it to be the case in this instance.
Any help would be greatly appreciated in clarifying this matter.
To get better response, can you submit this bug/issue to http://connect.microsoft.com? We can track it better there, thanks!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
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
2012年3月7日星期三
Disappearing Measures?
Not sure what I could have done to make this happen ... but one of my simple measures (simply a row count of my fact table) no longer shows a value EXCEPT when I use it with one of my multi-level hierarchies I defined.
Has anyone seen this?
Is there a way to fix it?
I really have no idea what I coulda done. I've even commented out my calculated members and removed any non-regular dimensions and it still ain't working.
Thanks - WaydeDoes your calculations script contain a CALCULATE command? Without this no aggregation will be done and only the leaf cells will contain data.
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.
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
Disappearing lines when rendering as an IMAGE
I found that lines/colors disappear starting from page 3 or 4 when rendering
report page by page in any IMAGE format (TIFF, Metafile, BMP)
When you render all pages at once into multipage TIFF - all lines/colors are
preserved.
It looks like bug to me.
I have SP1 installed and it did not fix the problemDoes it happen when you render single page starting from specific page?
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"SD" <SD@.discussions.microsoft.com> wrote in message
news:9B722DF5-84A3-4D3D-8272-F5590C142C2E@.microsoft.com...
>I found that lines/colors disappear starting from page 3 or 4 when
>rendering
> report page by page in any IMAGE format (TIFF, Metafile, BMP)
> When you render all pages at once into multipage TIFF - all lines/colors
> are
> preserved.
> It looks like bug to me.
> I have SP1 installed and it did not fix the problem|||Yes. It happens when I render single page in any image format.
"Lev Semenets [MSFT]" wrote:
> Does it happen when you render single page starting from specific page?
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "SD" <SD@.discussions.microsoft.com> wrote in message
> news:9B722DF5-84A3-4D3D-8272-F5590C142C2E@.microsoft.com...
> >I found that lines/colors disappear starting from page 3 or 4 when
> >rendering
> > report page by page in any IMAGE format (TIFF, Metafile, BMP)
> >
> > When you render all pages at once into multipage TIFF - all lines/colors
> > are
> > preserved.
> >
> > It looks like bug to me.
> > I have SP1 installed and it did not fix the problem
>
>
report page by page in any IMAGE format (TIFF, Metafile, BMP)
When you render all pages at once into multipage TIFF - all lines/colors are
preserved.
It looks like bug to me.
I have SP1 installed and it did not fix the problemDoes it happen when you render single page starting from specific page?
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"SD" <SD@.discussions.microsoft.com> wrote in message
news:9B722DF5-84A3-4D3D-8272-F5590C142C2E@.microsoft.com...
>I found that lines/colors disappear starting from page 3 or 4 when
>rendering
> report page by page in any IMAGE format (TIFF, Metafile, BMP)
> When you render all pages at once into multipage TIFF - all lines/colors
> are
> preserved.
> It looks like bug to me.
> I have SP1 installed and it did not fix the problem|||Yes. It happens when I render single page in any image format.
"Lev Semenets [MSFT]" wrote:
> Does it happen when you render single page starting from specific page?
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "SD" <SD@.discussions.microsoft.com> wrote in message
> news:9B722DF5-84A3-4D3D-8272-F5590C142C2E@.microsoft.com...
> >I found that lines/colors disappear starting from page 3 or 4 when
> >rendering
> > report page by page in any IMAGE format (TIFF, Metafile, BMP)
> >
> > When you render all pages at once into multipage TIFF - all lines/colors
> > are
> > preserved.
> >
> > It looks like bug to me.
> > I have SP1 installed and it did not fix the problem
>
>
Disappearing lines when rendering as an IMAGE
I'm having some problems rendering reports as images. We've been using PDF
rendering in the past and had no problems. However, when we switched over to
IMAGE we noticed that in reports with grid type layouts, some of the lines in
the grid would be missing. For example, a grid starting on the second page
of a particular report looks fine there, but on the next page all of the
gridlines are gone. On the next page I get the same result, but the
gridlines begin to show up again halfway down the page (within the same
grid). Any thoughts?
ThanksCould you create a sample report that demonstrates the problem and post it
to the newsgroup? Please use an embedded image and use one of the sample
databases as a data source.
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Boese" <Boese@.discussions.microsoft.com> wrote in message
news:77FC51EB-5F6B-48BF-95CF-84D138362FDD@.microsoft.com...
> I'm having some problems rendering reports as images. We've been using
PDF
> rendering in the past and had no problems. However, when we switched over
to
> IMAGE we noticed that in reports with grid type layouts, some of the lines
in
> the grid would be missing. For example, a grid starting on the second
page
> of a particular report looks fine there, but on the next page all of the
> gridlines are gone. On the next page I get the same result, but the
> gridlines begin to show up again halfway down the page (within the same
> grid). Any thoughts?
> Thanks|||It would probably be useful if I remembered to inclued the link...
http://www.rose-hulman.edu/~boeseaw/|||Increasing the border width should solve this problem.
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Boese" <Boese@.discussions.microsoft.com> wrote in message
news:8658F69E-CAF5-4F41-B925-38F6AC615618@.microsoft.com...
> It would probably be useful if I remembered to inclued the link...
> http://www.rose-hulman.edu/~boeseaw/
rendering in the past and had no problems. However, when we switched over to
IMAGE we noticed that in reports with grid type layouts, some of the lines in
the grid would be missing. For example, a grid starting on the second page
of a particular report looks fine there, but on the next page all of the
gridlines are gone. On the next page I get the same result, but the
gridlines begin to show up again halfway down the page (within the same
grid). Any thoughts?
ThanksCould you create a sample report that demonstrates the problem and post it
to the newsgroup? Please use an embedded image and use one of the sample
databases as a data source.
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Boese" <Boese@.discussions.microsoft.com> wrote in message
news:77FC51EB-5F6B-48BF-95CF-84D138362FDD@.microsoft.com...
> I'm having some problems rendering reports as images. We've been using
> rendering in the past and had no problems. However, when we switched over
to
> IMAGE we noticed that in reports with grid type layouts, some of the lines
in
> the grid would be missing. For example, a grid starting on the second
page
> of a particular report looks fine there, but on the next page all of the
> gridlines are gone. On the next page I get the same result, but the
> gridlines begin to show up again halfway down the page (within the same
> grid). Any thoughts?
> Thanks|||It would probably be useful if I remembered to inclued the link...
http://www.rose-hulman.edu/~boeseaw/|||Increasing the border width should solve this problem.
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Boese" <Boese@.discussions.microsoft.com> wrote in message
news:8658F69E-CAF5-4F41-B925-38F6AC615618@.microsoft.com...
> It would probably be useful if I remembered to inclued the link...
> http://www.rose-hulman.edu/~boeseaw/
Disappearing Datasets (MDX) in Report Designer
Hi,
we encountered a lot of problems with MDX-Datases in the CTP-verisons, but
now it's even worse!
We designed a little report against one of our cubes with only one Dataset
and immediate preview and saved it immediately. The report worked fine. Then
we clicked on the Dataset tab, and the filters and the levels (fields) are
EMPTY! Of course the next preview fails.
Closing the report asks if we want to save the changes, but we don't.
If we now re-open the project, it's just the same: preview o.k., click on
Dataset-tab -> EMPTY, changes were made!
What could be the problem?
If we re-open again and Click Preview, Dataset, Layout in this order,
"Visual Studio has encountered a problem and needs to close"!
Sometimes - we are not able to examine the exact conditions so far - VS
closes without any comment: We start the Report Designer and use
AdventureWorks as a new shared datasource. If the query builder opens we
switch into design mode. If the first action is a right-click into the
design-area, either VS disappears or "Visual Studio has encountered a
problem and needs to close"!.
Any ideas?
Regards,
RalphSee my WORKAROUND under: VS crashes when changing new MDX-report (4)
"Ralph Watermann" wrote:
> Hi,
> we encountered a lot of problems with MDX-Datases in the CTP-verisons, but
> now it's even worse!
> We designed a little report against one of our cubes with only one Dataset
> and immediate preview and saved it immediately. The report worked fine. Then
> we clicked on the Dataset tab, and the filters and the levels (fields) are
> EMPTY! Of course the next preview fails.
> Closing the report asks if we want to save the changes, but we don't.
> If we now re-open the project, it's just the same: preview o.k., click on
> Dataset-tab -> EMPTY, changes were made!
> What could be the problem?
> If we re-open again and Click Preview, Dataset, Layout in this order,
> "Visual Studio has encountered a problem and needs to close"!
> Sometimes - we are not able to examine the exact conditions so far - VS
> closes without any comment: We start the Report Designer and use
> AdventureWorks as a new shared datasource. If the query builder opens we
> switch into design mode. If the first action is a right-click into the
> design-area, either VS disappears or "Visual Studio has encountered a
> problem and needs to close"!.
> Any ideas?
> Regards,
> Ralph
>
>
>
we encountered a lot of problems with MDX-Datases in the CTP-verisons, but
now it's even worse!
We designed a little report against one of our cubes with only one Dataset
and immediate preview and saved it immediately. The report worked fine. Then
we clicked on the Dataset tab, and the filters and the levels (fields) are
EMPTY! Of course the next preview fails.
Closing the report asks if we want to save the changes, but we don't.
If we now re-open the project, it's just the same: preview o.k., click on
Dataset-tab -> EMPTY, changes were made!
What could be the problem?
If we re-open again and Click Preview, Dataset, Layout in this order,
"Visual Studio has encountered a problem and needs to close"!
Sometimes - we are not able to examine the exact conditions so far - VS
closes without any comment: We start the Report Designer and use
AdventureWorks as a new shared datasource. If the query builder opens we
switch into design mode. If the first action is a right-click into the
design-area, either VS disappears or "Visual Studio has encountered a
problem and needs to close"!.
Any ideas?
Regards,
RalphSee my WORKAROUND under: VS crashes when changing new MDX-report (4)
"Ralph Watermann" wrote:
> Hi,
> we encountered a lot of problems with MDX-Datases in the CTP-verisons, but
> now it's even worse!
> We designed a little report against one of our cubes with only one Dataset
> and immediate preview and saved it immediately. The report worked fine. Then
> we clicked on the Dataset tab, and the filters and the levels (fields) are
> EMPTY! Of course the next preview fails.
> Closing the report asks if we want to save the changes, but we don't.
> If we now re-open the project, it's just the same: preview o.k., click on
> Dataset-tab -> EMPTY, changes were made!
> What could be the problem?
> If we re-open again and Click Preview, Dataset, Layout in this order,
> "Visual Studio has encountered a problem and needs to close"!
> Sometimes - we are not able to examine the exact conditions so far - VS
> closes without any comment: We start the Report Designer and use
> AdventureWorks as a new shared datasource. If the query builder opens we
> switch into design mode. If the first action is a right-click into the
> design-area, either VS disappears or "Visual Studio has encountered a
> problem and needs to close"!.
> Any ideas?
> Regards,
> Ralph
>
>
>
Disappearing databases - HELP!
Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
Server, using MacAfee VirusScan Enterprise
Over the lunchtime, we seem to have lost several databases from a couple of
server groups on our server!
It appears no-one was working on the server at the time.
Does anyone know if there is a virus/worm which is capable of this?
Any ideas gratefully received ;-)
TIA
SteveCyberDwarf wrote:
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple of
> server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
Do you have Internet sites talking to these databases, and are those
sites properly protected from SQL injection attacks? Have you checked
the SQL logs to see if there are clues there? The Windows event logs?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy
Thx for your rapid reply.
No, there are no connections to this server from the Net.
Am in the process of checking the logs
Regards
Steve|||SQL Server log shows no unusual activity at all!!
Doh!|||On Wed, 9 Aug 2006 16:14:37 +0100, "CyberDwarf"
<steve.ingle@.lineone.net> wrote:
in <eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl>
>Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
>Server, using MacAfee VirusScan Enterprise
>Over the lunchtime, we seem to have lost several databases from a couple of
>server groups on our server!
>It appears no-one was working on the server at the time.
>Does anyone know if there is a virus/worm which is capable of this?
>Any ideas gratefully received ;-)
>TIA
>Steve
>
I've seen System Restore wipe out databases.
Stefan Berglund|||Cyber
As you're desribing the issue, it looks like (very sad to say) that
someone who has/have permissions just droped the databases. I have
experience at our shop unfortunatly.
"CyberDwarf" <steve.ingle@.lineone.net> wrote in message
news:eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl...
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple
> of server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
Server, using MacAfee VirusScan Enterprise
Over the lunchtime, we seem to have lost several databases from a couple of
server groups on our server!
It appears no-one was working on the server at the time.
Does anyone know if there is a virus/worm which is capable of this?
Any ideas gratefully received ;-)
TIA
SteveCyberDwarf wrote:
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple of
> server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
Do you have Internet sites talking to these databases, and are those
sites properly protected from SQL injection attacks? Have you checked
the SQL logs to see if there are clues there? The Windows event logs?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy
Thx for your rapid reply.
No, there are no connections to this server from the Net.
Am in the process of checking the logs
Regards
Steve|||SQL Server log shows no unusual activity at all!!
Doh!|||On Wed, 9 Aug 2006 16:14:37 +0100, "CyberDwarf"
<steve.ingle@.lineone.net> wrote:
in <eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl>
>Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
>Server, using MacAfee VirusScan Enterprise
>Over the lunchtime, we seem to have lost several databases from a couple of
>server groups on our server!
>It appears no-one was working on the server at the time.
>Does anyone know if there is a virus/worm which is capable of this?
>Any ideas gratefully received ;-)
>TIA
>Steve
>
I've seen System Restore wipe out databases.
Stefan Berglund|||Cyber
As you're desribing the issue, it looks like (very sad to say) that
someone who has/have permissions just droped the databases. I have
experience at our shop unfortunatly.
"CyberDwarf" <steve.ingle@.lineone.net> wrote in message
news:eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl...
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple
> of server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
Disappearing databases - HELP!
Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
Server, using MacAfee VirusScan Enterprise
Over the lunchtime, we seem to have lost several databases from a couple of
server groups on our server!
It appears no-one was working on the server at the time.
Does anyone know if there is a virus/worm which is capable of this?
Any ideas gratefully received ;-)
TIA
SteveCyberDwarf wrote:
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple o
f
> server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
Do you have Internet sites talking to these databases, and are those
sites properly protected from SQL injection attacks? Have you checked
the SQL logs to see if there are clues there? The Windows event logs?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy
Thx for your rapid reply.
No, there are no connections to this server from the Net.
Am in the process of checking the logs
Regards
Steve|||SQL Server log shows no unusual activity at all!!
Doh!|||On Wed, 9 Aug 2006 16:14:37 +0100, "CyberDwarf"
<steve.ingle@.lineone.net> wrote:
in <eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl>
>Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
>Server, using MacAfee VirusScan Enterprise
>Over the lunchtime, we seem to have lost several databases from a couple of
>server groups on our server!
>It appears no-one was working on the server at the time.
>Does anyone know if there is a virus/worm which is capable of this?
>Any ideas gratefully received ;-)
>TIA
>Steve
>
I've seen System Restore wipe out databases.
Stefan Berglund|||Cyber
As you're desribing the issue, it looks like (very sad to say) that
someone who has/have permissions just droped the databases. I have
experience at our shop unfortunatly.
"CyberDwarf" <steve.ingle@.lineone.net> wrote in message
news:eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl...
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple
> of server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
Server, using MacAfee VirusScan Enterprise
Over the lunchtime, we seem to have lost several databases from a couple of
server groups on our server!
It appears no-one was working on the server at the time.
Does anyone know if there is a virus/worm which is capable of this?
Any ideas gratefully received ;-)
TIA
SteveCyberDwarf wrote:
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple o
f
> server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
Do you have Internet sites talking to these databases, and are those
sites properly protected from SQL injection attacks? Have you checked
the SQL logs to see if there are clues there? The Windows event logs?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy
Thx for your rapid reply.
No, there are no connections to this server from the Net.
Am in the process of checking the logs
Regards
Steve|||SQL Server log shows no unusual activity at all!!
Doh!|||On Wed, 9 Aug 2006 16:14:37 +0100, "CyberDwarf"
<steve.ingle@.lineone.net> wrote:
in <eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl>
>Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
>Server, using MacAfee VirusScan Enterprise
>Over the lunchtime, we seem to have lost several databases from a couple of
>server groups on our server!
>It appears no-one was working on the server at the time.
>Does anyone know if there is a virus/worm which is capable of this?
>Any ideas gratefully received ;-)
>TIA
>Steve
>
I've seen System Restore wipe out databases.
Stefan Berglund|||Cyber
As you're desribing the issue, it looks like (very sad to say) that
someone who has/have permissions just droped the databases. I have
experience at our shop unfortunatly.
"CyberDwarf" <steve.ingle@.lineone.net> wrote in message
news:eWTymY8uGHA.4756@.TK2MSFTNGP02.phx.gbl...
> Running SQL Server 2000 - patched up to date, behind firewall, on Win2003
> Server, using MacAfee VirusScan Enterprise
> Over the lunchtime, we seem to have lost several databases from a couple
> of server groups on our server!
> It appears no-one was working on the server at the time.
> Does anyone know if there is a virus/worm which is capable of this?
> Any ideas gratefully received ;-)
> TIA
> Steve
>
订阅：
博文 (Atom)