Request for Feedback: Usage of xs:date and xs:dateTime and negative dates in SQL Server XM

Hi all
As part of the next version of SQL Server, we have to stop supporting
negative
years in the two types xs:dateTime and xs:date in the XML data type for
reasons I currently
cannot go into details.
The SQL Server product team would like your help in deciding on what upgrade
experience is acceptable. We would appreciate if you could do the following
if you are storing XML in your database that is constrained with an XML
schema collection (if you have customers, we would love to hear from their
databases, but please ask them first whether you can run the script):
1.. Consider the three upgrade options:
a. Database upgrade without size of data upgrade, affected tables, XML
Schema Collections and XML indexes will be taken offline. A built-in system
stored procedure will have to be run, that will perform the size of data
upgrade, change negative dates to a user-provided date that needs to be
positive and then recreates the indices and re-enables the tables and XML
Schema collections.
b. Database upgrade without size of data upgrade, affected XML indexes
will be taken offline. Creating an XML index and XQueries will fail if the
data queried/indexed contains a negative date or dateTime value. A built-in
system stored procedure will be provided, that for a given column will
perform the size of data upgrade, and change negative dates to a
user-provided date that needs to be positive. After this the query and index
creation can be run.
c. Database upgrade with size of data upgrade for every XML column that
can contain an xs:date or xs:dateTime value, affected XML indexes will be
taken offline. As part of the upgrade process, negative dates are mapped to
the smallest date 0001-01-01T00:00:00Z and the previous negative value will
be logged. Users then can recreate the XML indices.
2. run the attached script on your SQL Server database instance. Please
run it under an account that has the most data visibility. You can run it in
one of two ways:
A. run it to only gather metadata information. This is a short query
looking at the catalog views and does not impact the system performance in a
big way):
-- Just get the dependent columns per affected XML Schema Collection
exec DateTimeInvestigation 0
B. run it to gather metadata and data information. This may run a long
time
on the data and will most likely impact the system's performance, so please
run it only after making sure that this cost is acceptable:
-- Get the dependent columns per affected XML Schema Collection and
-- the number of affected values
exec DateTimeInvestigation 1
3. Please reply to this questionnaire by Monday, May 7 lunch time
providing your preferential ordering of 1.a to 1.c and attach the resulting
XML document from run of 2. Note that we are of course still taking
information from later runs but they may not be used for making this
decision if they arrive too late.
I and the rest of the SQL Server team highly appreciate your help with this.
Best regards
Michael Rys
Principal Program Manager
SQL Server Engine Team
(please remove the online. from the email address)
and here is the attached script.
"Michael Rys [MSFT]" <mrys@.online.microsoft.com> wrote in message
news:ObKsOUgjHHA.4188@.TK2MSFTNGP02.phx.gbl...
> Hi all
> As part of the next version of SQL Server, we have to stop supporting
> negative
> years in the two types xs:dateTime and xs:date in the XML data type for
> reasons I currently
> cannot go into details.
> The SQL Server product team would like your help in deciding on what
> upgrade
> experience is acceptable. We would appreciate if you could do the
> following
> if you are storing XML in your database that is constrained with an XML
> schema collection (if you have customers, we would love to hear from their
> databases, but please ask them first whether you can run the script):
> 1.. Consider the three upgrade options:
> a. Database upgrade without size of data upgrade, affected tables, XML
> Schema Collections and XML indexes will be taken offline. A built-in
> system
> stored procedure will have to be run, that will perform the size of data
> upgrade, change negative dates to a user-provided date that needs to be
> positive and then recreates the indices and re-enables the tables and XML
> Schema collections.
> b. Database upgrade without size of data upgrade, affected XML indexes
> will be taken offline. Creating an XML index and XQueries will fail if the
> data queried/indexed contains a negative date or dateTime value. A
> built-in
> system stored procedure will be provided, that for a given column will
> perform the size of data upgrade, and change negative dates to a
> user-provided date that needs to be positive. After this the query and
> index
> creation can be run.
> c. Database upgrade with size of data upgrade for every XML column that
> can contain an xs:date or xs:dateTime value, affected XML indexes will be
> taken offline. As part of the upgrade process, negative dates are mapped
> to
> the smallest date 0001-01-01T00:00:00Z and the previous negative value
> will
> be logged. Users then can recreate the XML indices.
> 2. run the attached script on your SQL Server database instance. Please
> run it under an account that has the most data visibility. You can run it
> in
> one of two ways:
> A. run it to only gather metadata information. This is a short query
> looking at the catalog views and does not impact the system performance in
> a
> big way):
> -- Just get the dependent columns per affected XML Schema Collection
> exec DateTimeInvestigation 0
> B. run it to gather metadata and data information. This may run a long
> time
> on the data and will most likely impact the system's performance, so
> please
> run it only after making sure that this cost is acceptable:
> -- Get the dependent columns per affected XML Schema Collection and
> -- the number of affected values
> exec DateTimeInvestigation 1
> 3. Please reply to this questionnaire by Monday, May 7 lunch time
> providing your preferential ordering of 1.a to 1.c and attach the
> resulting
> XML document from run of 2. Note that we are of course still taking
> information from later runs but they may not be used for making this
> decision if they arrive too late.
> I and the rest of the SQL Server team highly appreciate your help with
> this.
> Best regards
> Michael Rys
> Principal Program Manager
> SQL Server Engine Team
> (please remove the online. from the email address)
>

Request for confirmation: This bug is fixed

8.00.818 is the version number for the MS03-031 security=20
patch. It was released after SP3a.=20
/risun

>--Original Message--
>Hello World,
>One of our customers keeps getting the following error:
>ODBC error code: -1
>Net library error code: 2746x (10054)
>SQLState: 01000
>Description: ConnectionWrite(send())
>I have looked up on the Microsoft web pages and have=20
found:
>http://support.microsoft.com/kb/q303120/
>The description on this page states that this bug was=20
fixed with SQL=20
>Server 2000, service pack 2, so I asked the customer=20
about the server=20
>version number of his SQL Server 2000.
>He has 8.00.818 (and lightweight pooling to default,=20
which is off).=20
>Accorind to the SQL Server 2000, service pack 3=20
description, an=20
>installed SP3 has number 8.00.760.
>Due to this circumstances I suppose our customer has a=20
fixed version of=20
>SQL Server 2000 and the problem is located somewhere=20
else. Am I right?
>Thanks for your help and best regards
>Andreas
>--=20
>Andreas Tscharner =20
andreas.tscharner@.metromec.ch
>----
--
>Das Denken eines Programmierers ist stets logisch (IF 1=3D2=20
THEN CALL
>MainProgram), immer strukturiert und von keinerlei=20
Vorurteilen
>beeintr=E4chtigt (ON Hunger GOSUB Aldi ELSE RETURN).
> -- aus Murphy's=20
Computergesetzen
>.
>
Actually, 817 is the MS03-031 Slammer Worm build. 818 fixes an error MS03-031 introduced into the DTSGUI.dll and build 819 fixes a SQLEM password error introduced by the 818 fix. You should have build 819 to have all the tools fixed.
Also, there have been three other publicly available hot fixes since then, 839, 859, and the latest, 879.
Sincerely,
Anthony Thomas

"Risun" <anonymous@.discussions.microsoft.com> wrote in message news:4a1d01c4c65d$fad72b40$a601280a@.phx.gbl...
8.00.818 is the version number for the MS03-031 security
patch. It was released after SP3a.
/risun

>--Original Message--
>Hello World,
>
>One of our customers keeps getting the following error:
>
>ODBC error code: -1
>Net library error code: 2746x (10054)
>SQLState: 01000
>Description: ConnectionWrite(send())
>
>I have looked up on the Microsoft web pages and have

found:

>http://support.microsoft.com/kb/q303120/
>
>The description on this page states that this bug was

fixed with SQL

>Server 2000, service pack 2, so I asked the customer

about the server

>version number of his SQL Server 2000.
>He has 8.00.818 (and lightweight pooling to default,

which is off).

>Accorind to the SQL Server 2000, service pack 3

description, an

>installed SP3 has number 8.00.760.
>
>Due to this circumstances I suppose our customer has a

fixed version of

>SQL Server 2000 and the problem is located somewhere

else. Am I right?

>
>Thanks for your help and best regards
> Andreas
>--
>Andreas Tscharner

andreas.tscharner@.metromec.ch

>----

--

>Das Denken eines Programmierers ist stets logisch (IF 1=2

THEN CALL

>MainProgram), immer strukturiert und von keinerlei

Vorurteilen

>beeintrchtigt (ON Hunger GOSUB Aldi ELSE RETURN).
> -- aus Murphy's

Computergesetzen

>.
>|||Anthony,
Please stop confusing people by referring to build 817 (or 818 or 819
or MS03-031) as the "Slammer Worm build." This has nothing to do with
Slammer. As I've already pointed out, and as you can verify by reading
the security bulletins, MS03-031 addresses three post-Slammer
vulnerabilities. Like all Microsoft hotfixes, it is cumulative, but it
is definitely not the "Slammer Worm build," and it was released long
after the patch and service pack addressing the Slammer vulnerability
were released.
SK
AnthonyThomas wrote:

>Actually, 817 is the MS03-031 Slammer Worm build. 818 fixes an error MS03-031 introduced into the DTSGUI.dll and build 819 fixes a SQLEM password error introduced by the 818 fix. You should have build 819 to have all the tools fixed.
>Also, there have been three other publicly available hot fixes since then, 839, 859, and the latest, 879.
>Sincerely,
>
>Anthony Thomas
>
>
|||My apologies to everyone. You, of course, are absolutely right. The Sapphire/Slammer Worm attacked Jan. 25, 2003, but the patches were available the prior summer but had not been applied by many. Obviously, MS03-031 was deployed until later 2003. Both deal with protocol hijacking and buffer overrun issues and, since we had been applying SP3, then shortly thereafter, SP3a, this seemed like the proactive release.
The confusion was entirely my own.
Sincerely,
Anthony Thomas

"Steve Kass" <skass@.drew.edu> wrote in message news:uRlKFoi1EHA.208@.TK2MSFTNGP12.phx.gbl...
Anthony,
Please stop confusing people by referring to build 817 (or 818 or 819
or MS03-031) as the "Slammer Worm build." This has nothing to do with
Slammer. As I've already pointed out, and as you can verify by reading
the security bulletins, MS03-031 addresses three post-Slammer
vulnerabilities. Like all Microsoft hotfixes, it is cumulative, but it
is definitely not the "Slammer Worm build," and it was released long
after the patch and service pack addressing the Slammer vulnerability
were released.
SK
AnthonyThomas wrote:

>Actually, 817 is the MS03-031 Slammer Worm build. 818 fixes an error MS03-031 introduced into the DTSGUI.dll and build 819 fixes a SQLEM password error introduced by the 818 fix. You should have build 819 to have all the tools fixed.
>
>Also, there have been three other publicly available hot fixes since then, 839, 859, and the latest, 879.
>
>Sincerely,
>
>
>Anthony Thomas
>
>
>
>|||Thanks for clearing this up, Anthony!
SK
AnthonyThomas wrote:

>My apologies to everyone. You, of course, are absolutely right. The Sapphire/Slammer Worm attacked Jan. 25, 2003, but the patches were available the prior summer but had not been applied by many. Obviously, MS03-031 was deployed until later 2003. Bot
h deal with protocol hijacking and buffer overrun issues and, since we had been applying SP3, then shortly thereafter, SP3a, this seemed like the proactive release.
>The confusion was entirely my own.
>Sincerely,
>
>Anthony Thomas
>
>

Request for confirmation: This bug is fixed

8.00.818 is the version number for the MS03-031 security=20
patch. It was released after SP3a.=20
/risun

>--Original Message--
>Hello World,
>One of our customers keeps getting the following error:
>ODBC error code: -1
>Net library error code: 2746x (10054)
>SQLState: 01000
>Description: ConnectionWrite(send())
>I have looked up on the Microsoft web pages and have=20
found:
>http://support.microsoft.com/kb/q303120/
>The description on this page states that this bug was=20
fixed with SQL=20
>Server 2000, service pack 2, so I asked the customer=20
about the server=20
>version number of his SQL Server 2000.
>He has 8.00.818 (and lightweight pooling to default,=20
which is off).=20
>Accorind to the SQL Server 2000, service pack 3=20
description, an=20
>installed SP3 has number 8.00.760.
>Due to this circumstances I suppose our customer has a=20
fixed version of=20
>SQL Server 2000 and the problem is located somewhere=20
else. Am I right?
>Thanks for your help and best regards
> Andreas
>--=20
>Andreas Tscharner =20
andreas.tscharner@.metromec.ch
>----
--
>Das Denken eines Programmierers ist stets logisch (IF 1=3D2=20
THEN CALL
>MainProgram), immer strukturiert und von keinerlei=20
Vorurteilen
>beeintr=E4chtigt (ON Hunger GOSUB Aldi ELSE RETURN).
> -- aus Murphy's=20
Computergesetzen
>.
>Actually, 817 is the MS03-031 Slammer Worm build. 818 fixes an error MS03-0
31 introduced into the DTSGUI.dll and build 819 fixes a SQLEM password error
introduced by the 818 fix. You should have build 819 to have all the tools
fixed.
Also, there have been three other publicly available hot fixes since then, 8
39, 859, and the latest, 879.
Sincerely,
Anthony Thomas
--
"Risun" <anonymous@.discussions.microsoft.com> wrote in message news:4a1d01
c4c65d$fad72b40$a601280a@.phx.gbl...
8.00.818 is the version number for the MS03-031 security
patch. It was released after SP3a.
/risun

>--Original Message--
>Hello World,
>
>One of our customers keeps getting the following error:
>
>ODBC error code: -1
>Net library error code: 2746x (10054)
>SQLState: 01000
>Description: ConnectionWrite(send())
>
>I have looked up on the Microsoft web pages and have
found:
>http://support.microsoft.com/kb/q303120/
>
>The description on this page states that this bug was
fixed with SQL
>Server 2000, service pack 2, so I asked the customer
about the server
>version number of his SQL Server 2000.
>He has 8.00.818 (and lightweight pooling to default,
which is off).
>Accorind to the SQL Server 2000, service pack 3
description, an
>installed SP3 has number 8.00.760.
>
>Due to this circumstances I suppose our customer has a
fixed version of
>SQL Server 2000 and the problem is located somewhere
else. Am I right?
>
>Thanks for your help and best regards
> Andreas
>--
>Andreas Tscharner
andreas.tscharner@.metromec.ch
>----
--
>Das Denken eines Programmierers ist stets logisch (IF 1=2
THEN CALL
>MainProgram), immer strukturiert und von keinerlei
Vorurteilen
>beeintrchtigt (ON Hunger GOSUB Aldi ELSE RETURN).
> -- aus Murphy's
Computergesetzen
>.
>|||Anthony,
Please stop confusing people by referring to build 817 (or 818 or 819
or MS03-031) as the "Slammer Worm build." This has nothing to do with
Slammer. As I've already pointed out, and as you can verify by reading
the security bulletins, MS03-031 addresses three post-Slammer
vulnerabilities. Like all Microsoft hotfixes, it is cumulative, but it
is definitely not the "Slammer Worm build," and it was released long
after the patch and service pack addressing the Slammer vulnerability
were released.
SK
AnthonyThomas wrote:

>Actually, 817 is the MS03-031 Slammer Worm build. 818 fixes an error MS03-
031 introduced into the DTSGUI.dll and build 819 fixes a SQLEM password erro
r introduced by the 818 fix. You should have build 819 to have all the tool
s fixed.
>Also, there have been three other publicly available hot fixes since then,
839, 859, and the latest, 879.
>Sincerely,
>
>Anthony Thomas
>
>|||My apologies to everyone. You, of course, are absolutely right. The Sapphi
re/Slammer Worm attacked Jan. 25, 2003, but the patches were available the p
rior summer but had not been applied by many. Obviously, MS03-031 was deplo
yed until later 2003. Both deal with protocol hijacking and buffer overrun
issues and, since we had been applying SP3, then shortly thereafter, SP3a, t
his seemed like the proactive release.
The confusion was entirely my own.
Sincerely,
Anthony Thomas
--
"Steve Kass" <skass@.drew.edu> wrote in message news:uRlKFoi1EHA.208@.TK2MSF
TNGP12.phx.gbl...
Anthony,
Please stop confusing people by referring to build 817 (or 818 or 819
or MS03-031) as the "Slammer Worm build." This has nothing to do with
Slammer. As I've already pointed out, and as you can verify by reading
the security bulletins, MS03-031 addresses three post-Slammer
vulnerabilities. Like all Microsoft hotfixes, it is cumulative, but it
is definitely not the "Slammer Worm build," and it was released long
after the patch and service pack addressing the Slammer vulnerability
were released.
SK
AnthonyThomas wrote:

>Actually, 817 is the MS03-031 Slammer Worm build. 818 fixes an error MS0
3-031 introduced into the DTSGUI.dll and build 819 fixes a SQLEM password er
ror introduced by the 818 fix. You should have build 819 to have all the to
ols fixed.
>
>Also, there have been three other publicly available hot fixes since then
, 839, 859, and the latest, 879.
>
>Sincerely,
>
>
>Anthony Thomas
>
>
>
>|||Thanks for clearing this up, Anthony!
SK
AnthonyThomas wrote:

>My apologies to everyone. You, of course, are absolutely right. The Sapphire/Slam
mer Worm attacked Jan. 25, 2003, but the patches were available the prior summer but
had not been applied by many. Obviously, MS03-031 was deployed until later 2003.
Bot
h deal with protocol hijacking and buffer overrun issues and, since we had been applying SP3
, then shortly thereafter, SP3a, this seemed like the proactive release.
>The confusion was entirely my own.
>Sincerely,
>
>Anthony Thomas
>
>

Reprting services on XP

Hi,
Which combination of sql server and Reprting services do I need on winxp? (I
mean which version of RS and which version of SQL serevr)The system requirements are listed on
http://www.microsoft.com/sql/reporting/productinfo/sysreqs.asp but basically
you need the Developer Edition of both, which means that it can't be put
into production.
--
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to the newsgroups only, thanks.
"Ray Alirezaei" <ray@.my.com> wrote in message
news:uJdqc%23e6EHA.2452@.TK2MSFTNGP14.phx.gbl...
> Hi,
> Which combination of sql server and Reprting services do I need on winxp?
> (I mean which version of RS and which version of SQL serevr)
>

Reposting: Database Version Issue

I just installed SP2 for 2005 standard edition and am getting the following
error when trying to use report server:
"The version of the report server database is either in a format that is not
valid, or it cannot be read. The found version is 'C.0.8.54'. The expected
version is 'C.0.8.43'. To continue, update the version of the report server
database and verify access rights. (rsInvalidReportServerDatabase)"
When I go into Reporting service configuration tool, the update button
returns the following:
"The database version matches your Reporting services installation"
and the database version is reported as 'C.0.8.54'.
this is critical and I need to get this up and running again. Any ideas?
--
John Cleveland
Network Manager
Urban systems LtdHave you installed any SQL service packs BEFORE adding other parts
like 'reporting services'
Also, there was a critical patch sent through windows update that
updates SQL server. Not sure if that is causing you problems.
On Apr 13, 1:16 am, John Cleveland
<JohnClevel...@.discussions.microsoft.com> wrote:
> I just installed SP2 for 2005 standard edition and am getting the following
> error when trying to use report server:
> "The version of the report server database is either in a format that is not
> valid, or it cannot be read. The found version is 'C.0.8.54'. The expected
> version is 'C.0.8.43'. To continue, update the version of the report server
> database and verify access rights. (rsInvalidReportServerDatabase)"
> When I go into Reporting service configuration tool, the update button
> returns the following:
> "The database version matches your Reporting services installation"
> and the database version is reported as 'C.0.8.54'.
> this is critical and I need to get this up and running again. Any ideas?
> --
> John Cleveland
> Network Manager
> Urban systems Ltd|||SP1 was already installed. reporting services was installed pre sp1.
I've narrowed down the sequence of events that lead to this issue. It seems
there was a reporting services update that was installed without my knowledge
that was intended for sp2 installs. SP2 wasn't installed yet. even though
sp2 is now installed, i still get the error message listed previously.
--
John Cleveland
Network Manager
Urban systems Ltd
"gommo" wrote:
> Have you installed any SQL service packs BEFORE adding other parts
> like 'reporting services'
> Also, there was a critical patch sent through windows update that
> updates SQL server. Not sure if that is causing you problems.
> On Apr 13, 1:16 am, John Cleveland
> <JohnClevel...@.discussions.microsoft.com> wrote:
> > I just installed SP2 for 2005 standard edition and am getting the following
> > error when trying to use report server:
> >
> > "The version of the report server database is either in a format that is not
> > valid, or it cannot be read. The found version is 'C.0.8.54'. The expected
> > version is 'C.0.8.43'. To continue, update the version of the report server
> > database and verify access rights. (rsInvalidReportServerDatabase)"
> >
> > When I go into Reporting service configuration tool, the update button
> > returns the following:
> >
> > "The database version matches your Reporting services installation"
> >
> > and the database version is reported as 'C.0.8.54'.
> >
> > this is critical and I need to get this up and running again. Any ideas?
> >
> > --
> > John Cleveland
> > Network Manager
> > Urban systems Ltd
>
>|||Is there a possibility that you actually have two different db's and your
reportserver instance is pointed at the "wrong" one frm the POV of the one
that your web application thinks it should connect to?
This might have happened if the person applying the update is not the
administrator of the box. See
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=150&messageid=293213
It can also happen if you apply the update in the wrong identity, even if
you are an administrator (I know that from personal experience <sigh> FWIW
the ReportServer database has a sprocwhere this is hard coded. I kid you
not. I think it gets adjusted during upgrades with a file called
catalog.sql. )
Short version of the fix described in that thread: you have to stop IIS and
RS and copy the files that were truly upgraded to the correct location --
but you should probably read the thread.
HTH,
>L<
"John Cleveland" <JohnCleveland@.discussions.microsoft.com> wrote in message
news:C797E3E5-38CA-4547-AD46-2215A50529A4@.microsoft.com...
>I just installed SP2 for 2005 standard edition and am getting the following
> error when trying to use report server:
> "The version of the report server database is either in a format that is
> not
> valid, or it cannot be read. The found version is 'C.0.8.54'. The expected
> version is 'C.0.8.43'. To continue, update the version of the report
> server
> database and verify access rights. (rsInvalidReportServerDatabase)"
> When I go into Reporting service configuration tool, the update button
> returns the following:
> "The database version matches your Reporting services installation"
> and the database version is reported as 'C.0.8.54'.
> this is critical and I need to get this up and running again. Any ideas?
>
> --
> John Cleveland
> Network Manager
> Urban systems Ltd
>|||I actually have this fixed now, it was caused by the sp2 upgrade. I
uninstalled rs, reinstalled and applied sp2 once again and all is fine.
Reports cam back properly, but the data sources had to be reconfigured. No
biggie.
Thanks for your suggestions though.
--
John Cleveland
Network Manager
Urban systems Ltd
"Lisa Slater Nicholls" wrote:
> Is there a possibility that you actually have two different db's and your
> reportserver instance is pointed at the "wrong" one frm the POV of the one
> that your web application thinks it should connect to?
> This might have happened if the person applying the update is not the
> administrator of the box. See
> http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=150&messageid=293213
> It can also happen if you apply the update in the wrong identity, even if
> you are an administrator (I know that from personal experience <sigh> FWIW
> the ReportServer database has a sprocwhere this is hard coded. I kid you
> not. I think it gets adjusted during upgrades with a file called
> catalog.sql. )
> Short version of the fix described in that thread: you have to stop IIS and
> RS and copy the files that were truly upgraded to the correct location --
> but you should probably read the thread.
> HTH,
> >L<
>
> "John Cleveland" <JohnCleveland@.discussions.microsoft.com> wrote in message
> news:C797E3E5-38CA-4547-AD46-2215A50529A4@.microsoft.com...
> >I just installed SP2 for 2005 standard edition and am getting the following
> > error when trying to use report server:
> >
> > "The version of the report server database is either in a format that is
> > not
> > valid, or it cannot be read. The found version is 'C.0.8.54'. The expected
> > version is 'C.0.8.43'. To continue, update the version of the report
> > server
> > database and verify access rights. (rsInvalidReportServerDatabase)"
> >
> > When I go into Reporting service configuration tool, the update button
> > returns the following:
> >
> > "The database version matches your Reporting services installation"
> >
> > and the database version is reported as 'C.0.8.54'.
> >
> > this is critical and I need to get this up and running again. Any ideas?
> >
> >
> > --
> > John Cleveland
> > Network Manager
> > Urban systems Ltd
> >
>

Repost: Installation trouble

Removed the previous version and tried installing the new trial - was able
to see reports in visual but not in reportmanager. So now I tried to drop it
all including all iis-catalogues and installed it from scratch again.
No luck...
My goal is just to get it running to see reports - not to get it running
with the right security settings...so in IIS i changed reports and
reportserver to anonymous access and then stopped and started iis and
reportserver service.
But when activating reportmanager it keeps on saying:
unable to finde script library
'/aspnet_client/system_web/1_1_4322/webuivalidation.js - try placing this
file manually or reinstall by running 'aspnet_regiis -c'
tried running to above and tried aspnet_regiis -i - no luck.
Have an xp operating system - is there a platform limitation for the trial
version ?
Is it related to my IIS-settings ? It shouldn't try to get the file above
when using anonymous access. I have had the previous version to function.
--MichaelNo hints ?
When using reportmanager I can do nothing in there - tried to make a
datasource but nothing happens when trying to save it. When switching from
one tab to another the error below pops up...
"Michael Vardinghus" <michaelvardinghus@.notexisting.com> skrev i en
meddelelse news:eJGqdb4kEHA.3984@.TK2MSFTNGP14.phx.gbl...
> Removed the previous version and tried installing the new trial - was able
> to see reports in visual but not in reportmanager. So now I tried to drop
it
> all including all iis-catalogues and installed it from scratch again.
> No luck...
> My goal is just to get it running to see reports - not to get it running
> with the right security settings...so in IIS i changed reports and
> reportserver to anonymous access and then stopped and started iis and
> reportserver service.
> But when activating reportmanager it keeps on saying:
> unable to finde script library
> '/aspnet_client/system_web/1_1_4322/webuivalidation.js - try placing this
> file manually or reinstall by running 'aspnet_regiis -c'
> tried running to above and tried aspnet_regiis -i - no luck.
> Have an xp operating system - is there a platform limitation for the trial
> version ?
> Is it related to my IIS-settings ? It shouldn't try to get the file above
> when using anonymous access. I have had the previous version to function.
> --Michael
>|||Not quite sure what did the trick but now it's working ...
"Michael Vardinghus" <michaelvardinghus@.notexisting.com> skrev i en
meddelelse news:%23lDRJ8OlEHA.3760@.TK2MSFTNGP12.phx.gbl...
> No hints ?
> When using reportmanager I can do nothing in there - tried to make a
> datasource but nothing happens when trying to save it. When switching from
> one tab to another the error below pops up...
> "Michael Vardinghus" <michaelvardinghus@.notexisting.com> skrev i en
> meddelelse news:eJGqdb4kEHA.3984@.TK2MSFTNGP14.phx.gbl...
> > Removed the previous version and tried installing the new trial - was
able
> > to see reports in visual but not in reportmanager. So now I tried to
drop
> it
> > all including all iis-catalogues and installed it from scratch again.
> >
> > No luck...
> >
> > My goal is just to get it running to see reports - not to get it running
> > with the right security settings...so in IIS i changed reports and
> > reportserver to anonymous access and then stopped and started iis and
> > reportserver service.
> >
> > But when activating reportmanager it keeps on saying:
> >
> > unable to finde script library
> > '/aspnet_client/system_web/1_1_4322/webuivalidation.js - try placing
this
> > file manually or reinstall by running 'aspnet_regiis -c'
> >
> > tried running to above and tried aspnet_regiis -i - no luck.
> >
> > Have an xp operating system - is there a platform limitation for the
trial
> > version ?
> >
> > Is it related to my IIS-settings ? It shouldn't try to get the file
above
> > when using anonymous access. I have had the previous version to
function.
> >
> > --Michael
> >
> >
>