Wednesday, March 28, 2012
Problem with SQL Service Pack 4
install says it completed but after I rebooted and did a select @.@.version it
still shows SP3. I only have a default instance so I know that it installed
on the right instance. Could anyone help me out with this?You can review the setup log for any errors (file called sqlsp.log in the
windows directory). It is perfectly safe to run SP4 again to try and make it
stick (assuming you have the system database backups just in case you need
to regress)
--
HTH,
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
"Leon Parker" <u23479@.uwe> wrote in message news:625d255c1f101@.uwe...
>I upgraded from SQL 2000 Service Pack 3 to SQL 2000 Service Pack 4. The
> install says it completed but after I rebooted and did a select @.@.version
> it
> still shows SP3. I only have a default instance so I know that it
> installed
> on the right instance. Could anyone help me out with this?|||I tried it several times but got the same result.
I've attached a copy of my sqlsp.log file. I looked at the sqlsp.log file
and it only listed one non-fatal error...I can't see this being the problem
considering it was nonfatal.
Jasper Smith wrote:
>You can review the setup log for any errors (file called sqlsp.log in the
>windows directory). It is perfectly safe to run SP4 again to try and make it
>stick (assuming you have the system database backups just in case you need
>to regress)
>>I upgraded from SQL 2000 Service Pack 3 to SQL 2000 Service Pack 4. The
>> install says it completed but after I rebooted and did a select @.@.version
>> it
>> still shows SP3. I only have a default instance so I know that it
>> installed
>> on the right instance. Could anyone help me out with this?|||What does the following query return?
SELECT SERVERPROPERTY('ProductLevel')
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Leon Parker" <u23479@.uwe> wrote in message news:625d255c1f101@.uwe...
>I upgraded from SQL 2000 Service Pack 3 to SQL 2000 Service Pack 4. The
> install says it completed but after I rebooted and did a select @.@.version
> it
> still shows SP3. I only have a default instance so I know that it
> installed
> on the right instance. Could anyone help me out with this?|||SP3....
Dan Guzman wrote:
>What does the following query return?
> SELECT SERVERPROPERTY('ProductLevel')
>>I upgraded from SQL 2000 Service Pack 3 to SQL 2000 Service Pack 4. The
>> install says it completed but after I rebooted and did a select @.@.version
>> it
>> still shows SP3. I only have a default instance so I know that it
>> installed
>> on the right instance. Could anyone help me out with this?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200606/1sql
Friday, March 9, 2012
Problem with report viewer
Hi,
I recently upgraded by ASP.Net 1.1 application to 2.0. 1.1 application was using awReportViewer to view the reports.
But, when upgraded, awreportViewer doesnt display the RS2005 enhancements like sorting, etc...so I decided to replace it with Report Viewer control in VS2005.
Now the problem starts, Whenever I try accesing the reports through application, it gives me error "Client found response content type of '', but expected 'text/xml'.
The request failed with an empty response."
This is how I have coded,
ReportViewer1.ProcessingMode = ProcessingMode.Remote
ReportViewer1.ServerReport.ReportServerUrl = New Uri(http://localhost/ReportServer/reportservice.asmx)
ReportViewer1.ServerReport.ReportPath = reportname
//Some code to set parameters in Report Paramater "parameters"
ReportViewer1.ServerReport.SetParameters(parameters)
My questions:
1. Am I going wrong somewhere in the above code?
2. Can awReportViewer be modified / upgraded so that it can support RS2005 features like sorting, multivalued parameters?
TIA
Tanmaya
Change the ReportServerUrl to be 'http://localhost/reportserver' and you should be in business.|||Great...its working now...thanks a ton :)Wednesday, March 7, 2012
Problem with query, involving INNER HASH JOIN
I've got 2 problems with the following statement, which leads me to
believe there is a bug somewhere.
This weekend we upgraded from SQL7 to SQL2000 (SP3) and it all went
smoothly except for this statement below 'losing' a couple of records.
It is contained in a stored procedure (believe me you don't want to
see it) and gives me 2 problems.
1. It seems depending on the parameters passed which affect the volume
of records being processed all the records either come through or not.
Now I KNOW the record is in ALWAYS in #TEMP1 (don't question it is as
I'm sure) as I debug it just before the insert. When I change the temp
table to a permanent table and run the raw SQL through QA using this
permanent table it always gets inserted and never loses the record,
hence I know it's not the join leading to the record not coming
through
2. Now the strange thing is if I add 'INNER HASH JOIN' to the 2 joins
then the record is lost but 8 records do come through, but if I just
make it a 'JOIN' then absolutely nothing comes through. Why is this?
How come removing the 'INNER HASH' reduce the number of records?
I know this sounds a bit of a ramble but I've spent several hours
investigating this and still have no idea. What I was wondering is has
anyone had any problems when upgrading with joins/temp tables/stored
procs somehow not selecting all the records expected?
SQL:
INSERT INTO #TEMP2(Day, Year, DataSource, StartDate,
MaturityDate, BusinessDayDate, DealID, TradeNum, Flowsign, Currency,
CurrencyUnit, ReportingCurrency,InstrumentType, ChangeType, FXRate,
SetNumber)
SELECT DISTINCT
@.StartDate,
DATEPART(Year,@.BusinessDayDate),
TRB.DataSource,
@.StartDate,
TP.MaturityDate,
TRB.BusinessDate,
TRB.DealNo,
TRB.TradeNo,
TRB.Flowsign,
TP.CurrencyCode,
TRB.CurrencyUnit,
@.RepCurrency,
TRB.Instrument,
TP.ChangeType,
ER.Rate,
1
FROM TCH_gt_TradeProfile TP
-- remove 'INNER HASH' join from here
JOIN #TEMP1 TRB ON TRB.DealNo = TP.DealID
AND TRB.TradeNo = TP.TradeNum
AND TRB.Currency = TP.CurrencyCode
-- remove 'INNER HASH' join from here
JOIN TCH_t_ExchangeRate ER ON TRB.Currency = ER.CcyCode
AND ER.ValidFrom <= @.BusinessDayDate
AND ER.ValidTo >= @.BusinessDayDate
WHERE @.BusinessDayDate > TP.BusinessDayValidFrom
AND @.BusinessDayDate <= TP.BusinessDayValidTo
AND (TP.ChangeType = @.ChangeType OR @.ChangeType = 'All')Please post DDL and data that demonstrates the problem. If you have a
parallel plan, try adding the MAXDOP 1 optimizer hint to see if that
fixes the problem.
--
Hope this helps.
Dan Guzman
SQL Server MVP
--
SQL FAQ links (courtesy Neil Pike):
http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--
"Rob Jones" <rob.jones@.barclays.co.uk> wrote in message
news:97dbfc5b.0308180057.2bbe0bea@.posting.google.com...
> Hi all,
> I've got 2 problems with the following statement, which leads me to
> believe there is a bug somewhere.
> This weekend we upgraded from SQL7 to SQL2000 (SP3) and it all went
> smoothly except for this statement below 'losing' a couple of records.
> It is contained in a stored procedure (believe me you don't want to
> see it) and gives me 2 problems.
> 1. It seems depending on the parameters passed which affect the volume
> of records being processed all the records either come through or not.
> Now I KNOW the record is in ALWAYS in #TEMP1 (don't question it is as
> I'm sure) as I debug it just before the insert. When I change the temp
> table to a permanent table and run the raw SQL through QA using this
> permanent table it always gets inserted and never loses the record,
> hence I know it's not the join leading to the record not coming
> through
> 2. Now the strange thing is if I add 'INNER HASH JOIN' to the 2 joins
> then the record is lost but 8 records do come through, but if I just
> make it a 'JOIN' then absolutely nothing comes through. Why is this?
> How come removing the 'INNER HASH' reduce the number of records?
> I know this sounds a bit of a ramble but I've spent several hours
> investigating this and still have no idea. What I was wondering is has
> anyone had any problems when upgrading with joins/temp tables/stored
> procs somehow not selecting all the records expected?
>
> SQL:
> INSERT INTO #TEMP2(Day, Year, DataSource, StartDate,
> MaturityDate, BusinessDayDate, DealID, TradeNum, Flowsign, Currency,
> CurrencyUnit, ReportingCurrency,InstrumentType, ChangeType, FXRate,
> SetNumber)
> SELECT DISTINCT
> @.StartDate,
> DATEPART(Year,@.BusinessDayDate),
> TRB.DataSource,
> @.StartDate,
> TP.MaturityDate,
> TRB.BusinessDate,
> TRB.DealNo,
> TRB.TradeNo,
> TRB.Flowsign,
> TP.CurrencyCode,
> TRB.CurrencyUnit,
> @.RepCurrency,
> TRB.Instrument,
> TP.ChangeType,
> ER.Rate,
> 1
> FROM TCH_gt_TradeProfile TP
> -- remove 'INNER HASH' join from here
> JOIN #TEMP1 TRB ON TRB.DealNo = TP.DealID
> AND TRB.TradeNo = TP.TradeNum
> AND TRB.Currency = TP.CurrencyCode
> -- remove 'INNER HASH' join from here
> JOIN TCH_t_ExchangeRate ER ON TRB.Currency = ER.CcyCode
> AND ER.ValidFrom <=> @.BusinessDayDate
> AND ER.ValidTo >=> @.BusinessDayDate
> WHERE @.BusinessDayDate > TP.BusinessDayValidFrom
> AND @.BusinessDayDate <= TP.BusinessDayValidTo
> AND (TP.ChangeType = @.ChangeType OR @.ChangeType => 'All')
Monday, February 20, 2012
Problem with Outlook BCM database upgrade
somebody knows the answer?