Invalid Path message

In the following code, I received an error on

execInfo = rsReportExec.LoadReport(strReportPath, strHistoryID). The errro was "System.Web.Services.Protocols.SoapException: The path of the item "http://localhost/ReportServer/Pages/ReportViewer.aspx?/CAITReports/rptIssuesByRole&rs:Command=Render&intProjectID=119&nvchrWhoRan=DYW" is not valid. The path must be less than 260 characters long and must start with slash. Other restrictions apply. > Microsoft.ReportingServices.Diagnostics.Utilities.InvalidItemPathException: The path of the item "http://localhost/ReportServer/Pages/ReportViewer.aspx?/CAITReports/rptIssuesByRole&rs:Command=Render&intProjectID=119&nvchrWhoRan=DYW" is not valid. The path must be less than 260 characters long and must start with slash. Other restrictions apply.

I copied and pasted the path on the URL and it worked. What did I miss in the code? Why strHistoryID is required as it is nothing? Please refer to http://msdn2.microsoft.com/en-us/library/microsoft.wssux.reportingserviceswebservice.rsexecutionservice2005.reportexecutionservice.render.aspx

Private Sub sExecuteReportingServicesReport()

Dim rsReportExec As ReportExecutionService = New ReportExecutionService

rsReportExec.Credentials = System.Net.CredentialCache.DefaultCredentials

'rsReportExec.Url = "http://localhost/reportserver/ReportExecution2005.asmx"

Dim byteResult() As Byte = Nothing

Dim strReportPath As String = "http://localhost/ReportServer/Pages/ReportViewer.aspx?/CAITReports/rptIssuesByRole&rs:Command=Render&intProjectID=" & Me.cboProject.SelectedValue & "&nvchrWhoRan=" & Session("strEmployeeName")

'Dim strReportPath As String = "/Pages/ReportViewer.aspx?/CAIT/rptIssuesByRole&rs:Command=Render&intProjectID=" & Me.cboProject.SelectedValue & "&nvchrWhoRan=" & Session("strEmployeeName")

Dim strFormat As String = "MSWord"

Dim strHistoryID As String = Nothing

Dim strEncoding As String = ""

Dim strMineType As String = ""

Dim strExtension As String = ""

Dim wrnWarnings() As Warning = Nothing

Dim strStreamIDs() As String = Nothing

Dim execInfo As New ExecutionInfo

Dim execHeader As New ExecutionHeader

rsReportExec.ExecutionHeaderValue = execHeader

execInfo = rsReportExec.LoadReport(strReportPath, strHistoryID)

Dim strSessionID As String = rsReportExec.ExecutionHeaderValue.ExecutionID

byteResult = rsReportExec.Render(strFormat, Nothing, strExtension, strEncoding, strMineType, wrnWarnings, strStreamIDs)

Response.ClearContent()

Response.AppendHeader("content-length", byteResult.Length.ToString)

Response.ContentType = "application/MSWord"

Response.BinaryWrite(byteResult)

Response.Flush()

Response.Close()

End Sub

Thanks.

DanYeung

The report path should be like /ReportFolder/ReportName

What you have given is URL. Check it for yourself in the msdn link you have given. There is nothing to do with hitory id.

Shyam

Invalid Logical Page

When trying to DTS a table (Auth_Details) from one database to another, I received the following error message:
Error at Source for row number 296443, Errors encountered so far in this task: 1
Attempt to fetch logica page (1:566896) in database abc belongs to object 'Ben_Tables', not to object 'Auth_Details'.
Can anyone tell me what may cause this and how to get rid of the problem?
Thanks,
Joe
Seems you have a corruption in your database. Here's some generic info:
http://www.karaszi.com/sqlserver/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"JoeA" <anonymous@.discussions.microsoft.com> wrote in message
news:8027A9B8-23E8-4F1A-945C-5A5328CC9B0D@.microsoft.com...
> When trying to DTS a table (Auth_Details) from one database to another, I received the following error
message:
> Error at Source for row number 296443, Errors encountered so far in this task: 1
> Attempt to fetch logica page (1:566896) in database abc belongs to object 'Ben_Tables', not to object
'Auth_Details'.
> Can anyone tell me what may cause this and how to get rid of the problem?
> Thanks,
> Joe

Invalid Logical Page

When trying to DTS a table (Auth_Details) from one database to another, I re
ceived the following error message:
Error at Source for row number 296443, Errors encountered so far in this tas
k: 1
Attempt to fetch logica page (1:566896) in database abc belongs to object 'B
en_Tables', not to object 'Auth_Details'.
Can anyone tell me what may cause this and how to get rid of the problem?
Thanks,
JoeSeems you have a corruption in your database. Here's some generic info:
http://www.karaszi.com/sqlserver/in..._suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"JoeA" <anonymous@.discussions.microsoft.com> wrote in message
news:8027A9B8-23E8-4F1A-945C-5A5328CC9B0D@.microsoft.com...
> When trying to DTS a table (Auth_Details) from one database to another, I received
the following error
message:
> Error at Source for row number 296443, Errors encountered so far in this t
ask: 1
> Attempt to fetch logica page (1:566896) in database abc belongs to object 'Ben_Tab
les', not to object
'Auth_Details'.
> Can anyone tell me what may cause this and how to get rid of the problem?
> Thanks,
> Joesql

Invalid column name using BCP

Hi,

I am having trouble creating the data files. I received the error that there is an invalid column name 'Name' when using the BCP to create the files. How can I find out where this error is coming from?

Thanks

Quote:

Originally Posted by sarah21

Hi,

I am having trouble creating the data files. I received the error that there is an invalid column name 'Name' when using the BCP to create the files. How can I find out where this error is coming from?

Thanks

Sarah,

Name is a funny word in SQL Server as it is also a programming command and that is why you may be experiencing problems, try putting the column name in [] or change column name to be something more meaingfull like FullName.

Hope that helps

Invalid buffer received from client..

Invalid buffer received from client..
Error: 17805, Severity: 20, State: 3
Anybody else has this? Any rumors about a fix to it?I know SQL SP3 has added a bunch of new error messages for things we were all blissfully unaware of before. This looks like one of them. If this is taking your server down, you can look into the fix on KB article 818897.|||That's where I started, but realized that this patch eliminates the AV, not the fact that the proc will fail anyway and the error will sill post.

I found a similar issue raised in ms sqlserver news group, where they had a declaration discrepancy between a passed NVARCHAR param and param definition in the proc (VARCHAR). Once they mirrored the definitions the error disappeared. In our case there is nothing to change, on both sides the parm declared as TEXT (or so my developers say it is on FE). Of course, I'll make sure they're not "exagerating" :), but the fact stays for now, - TEXT = TEXT.

Invalid buffer received from client.

I'm having seriouos trouble after installing SP4. I have an application writ
ten in ASP.NET 1.1 which worked fine with SQL 2000 SP3, but after upgrading
to SP4, the application totally crashed while trying to access the database.
It gives an error saying a
severe error has occued on the server. The
event log on the server has the following logged:
Error: 17805, Severity: 20, State: 3
Invalid buffer received from client.
For more information, see Help and Support Center at http://go.microsoft.com/fwlin
k/events.asp.
I'm sure it's SP4 because after I reinstalled SQL Server with SP3, everythin
g worked fine again. The server is running Windows 2003 SP1.
Anyone else having this problem or have a solution?Sp4 reduces the network packet size to 32767. Consider adjusting your app to
avoid the error.
<quote>
In SP4, the maximum value for the network packet size option (set using
sp_configure) is 32767. This is slightly less than half the previous maximum
of 65536. During upgrade, existing values larger than 32767 will
automatically be adjusted to 32767. If a script attempts to use sp_configure
to set a value larger than 32767 but less than or equal to 65536, the value
will also be set to 32767. Setting the network packet size to a value larger
than 65536 results in an error.
</quote>
There's used to be a bug even when the network packet size was set to
65535...
http://support.microsoft.com/kb/875411
-oj
"Watery" <waterydan@.hotmail.com> wrote in message
news:42813312@.duster.adelaide.on.net...
> I'm having seriouos trouble after installing SP4. I have an application
> written in ASP.NET 1.1 which worked fine with SQL 2000 SP3, but after
> upgrading to SP4, the application totally crashed while trying to access
> the database. It gives an error saying a severe error has occued on the
> server. The event log on the server has the following logged:
> Error: 17805, Severity: 20, State: 3
> Invalid buffer received from client.
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
> I'm sure it's SP4 because after I reinstalled SQL Server with SP3,
> everything worked fine again. The server is running Windows 2003 SP1.
> Anyone else having this problem or have a solution?|||Thanks oj...
Do you have an example of how to change the packet size to 32767 - is it thr
ough the connection string? At the moment, it has packet size set to 4096.
oj wrote:
> Sp4 reduces the network packet size to 32767. Consider adjusting your app
to
> avoid the error.
> <quote>
> In SP4, the maximum value for the network packet size option (set using
> sp_configure) is 32767. This is slightly less than half the previous maxim
um
> of 65536. During upgrade, existing values larger than 32767 will
> automatically be adjusted to 32767. If a script attempts to use sp_configu
re
> to set a value larger than 32767 but less than or equal to 65536, the valu
e
> will also be set to 32767. Setting the network packet size to a value larg
er
> than 65536 results in an error.
> </quote>
> There's used to be a bug even when the network packet size was set to
> 65535...
> http://support.microsoft.com/kb/875411
>|||Yes. You want to specify the "Packet Size=xxx" in your connectionstring.
According to the article, you might want to limit each of your insert batch
to 32767 rows.
-oj
"Watery" <waterydan@.hotmail.com> wrote in message
news:42817d1b$1@.duster.adelaide.on.net...
> Thanks oj...
> Do you have an example of how to change the packet size to 32767 - is it
> through the connection string? At the moment, it has packet size set to
> 4096.
> oj wrote:|||I tried what you suggested but with no vail.
Here's my connection string:
UID=user;PWD=password;Initial Catalog=DatabaseName;Data Source=ServerName;Pa
cket Size=4096;
I tried the packet size 2048, 1024, 768 but they all return the same error.
Any help is greatly appreciated!
oj wrote:
> Yes. You want to specify the "Packet Size=xxx" in your connectionstring.
> According to the article, you might want to limit each of your insert batc
h
> to 32767 rows.
>|||Perhaps, you want to explicitly define the sqldbtype for the sqlparameter
and be sure the length is not exceeding the allowable for the specified
type.
If you post your code (.Net call + sql), someone will take a closer look.
-oj
"Watery" <waterydan@.hotmail.com> wrote in message
news:428293aa$1@.duster.adelaide.on.net...
>I tried what you suggested but with no vail.
> Here's my connection string:
> UID=user;PWD=password;Initial Catalog=DatabaseName;Data
> Source=ServerName;Packet Size=4096;
> I tried the packet size 2048, 1024, 768 but they all return the same
> error.
> Any help is greatly appreciated!
> oj wrote:|||Thanks oj... I changed my code as you suggested and it is now working! :)
But now it runs extremely slow and frequently timeout. Any solution to this
problem as well?
oj wrote:
> Perhaps, you want to explicitly define the sqldbtype for the sqlparameter
> and be sure the length is not exceeding the allowable for the specified
> type.
> If you post your code (.Net call + sql), someone will take a closer look.
>|||Double check your sql to make sure proper indexes installed. Check out these
to see if they help:
http://support.microsoft.com/?id=308049
http://support.microsoft.com/kb/224587/
-oj
"Watery" <waterydan@.hotmail.com> wrote in message
news:4282bc9e@.duster.adelaide.on.net...
> Thanks oj... I changed my code as you suggested and it is now working! :)
> But now it runs extremely slow and frequently timeout. Any solution to
> this problem as well?
>
> oj wrote:|||Thanks oj... It's working fine now...
The problem was caused by creating an SQL parameter using DbType instead of
SqlDbType. I was trying to create a generic data provider that connects to b
oth Oracle and SQL Server. Now I think I have to map the individual DbType t
o SqlDbType.
Anyway, thanks for your help!! Much appreciated!
oj wrote:
> Double check your sql to make sure proper indexes installed. Check out the
se
> to see if they help:
> http://support.microsoft.com/?id=308049
> http://support.microsoft.com/kb/224587/
>|||You're very welcome.
-oj
"Watery" <waterydan@.hotmail.com> wrote in message
news:4282ce51@.duster.adelaide.on.net...
> Thanks oj... It's working fine now...
> The problem was caused by creating an SQL parameter using DbType instead
> of SqlDbType. I was trying to create a generic data provider that connects
> to both Oracle and SQL Server. Now I think I have to map the individual
> DbType to SqlDbType.
> Anyway, thanks for your help!! Much appreciated!
> oj wrote:

Invalid buffer received from client

Error: 17805, Severity: 20, State: 3
Invalid buffer received from client.
We just restored a SQL SRV 7 database to a SQL SRV 2000 on a new server.
The front end application is in VB 6. The above error message is being
logged in the server event viewer approximatly 30 times a day. Any
suggestions on any corrective action would be appreciated.Try to look if you have any types mismatch between front
end and SQL Server objects. For example type mistmach
between stored procedure parameter and front end variable
which you are trying to pass to this SP.
Regards.
----
All information provided above AS IS.
>--Original Message--
>Error: 17805, Severity: 20, State: 3
>Invalid buffer received from client.
>We just restored a SQL SRV 7 database to a SQL SRV 2000
on a new server.
>The front end application is in VB 6. The above error
message is being
>logged in the server event viewer approximatly 30 times a
day. Any
>suggestions on any corrective action would be appreciated.
>
>.
>|||Also it can happen if your clients MDAC is outdated.
Regards.
---
All information provided above AS IS.
>--Original Message--
>Error: 17805, Severity: 20, State: 3
>Invalid buffer received from client.
>We just restored a SQL SRV 7 database to a SQL SRV 2000
on a new server.
>The front end application is in VB 6. The above error
message is being
>logged in the server event viewer approximatly 30 times a
day. Any
>suggestions on any corrective action would be appreciated.
>
>.
>

Internet password attacks

I have opened port 1433 on our firewall to allow employees to access our SQL
server database and immediately we have received aggressive password attacks
,
mostly against the 'sa' user id. The 'sa' passoword is strong, but I'm
annoyed with the attacks that make my log files huge and cause unncessary
hits to the server.
Is there a way to configure SQL Server to force a delay between login
attempts or to temporarily lockout a user out as can be done with Windows
Server?
Many Thanks!Microsoft refuses to fix this glaring problem in SQL 2000. You can use a
port monitor to get the IP numbers then block them with a firewall or use
IPsec to block the IP numbers. It is a never ending job as new drones will
be attacking every day.
Microsoft's reply is that you shouldn't be doing this. Of course, they will
be glad to sell you a copy of SQL Server 2005 that does fix this (non)
problem.
With a strong password, the attackers will never be successful, but they can
eat up a lot of bandwidth trying.
Russ Stevens|||So you can confirm SQL 2005 does address this issue? Do you have details on
how?
I have port 1433 and 1434 open also going thru a Virtual IP, so far no
attacks.
"Russell Stevens" <rustyprogrammer@.online.nospam> wrote in message
news:um$43caqFHA.3524@.tk2msftngp13.phx.gbl...
> Microsoft refuses to fix this glaring problem in SQL 2000. You can use a
> port monitor to get the IP numbers then block them with a firewall or use
> IPsec to block the IP numbers. It is a never ending job as new drones will
> be attacking every day.
> Microsoft's reply is that you shouldn't be doing this. Of course, they
> will be glad to sell you a copy of SQL Server 2005 that does fix this
> (non) problem.
> With a strong password, the attackers will never be successful, but they
> can eat up a lot of bandwidth trying.
> Russ Stevens
>|||Rob,
<<So you can confirm SQL 2005 does address this issue? Do you have details
on
how?>>
SQL 2005 uses the normal Windows 2003 logon stuff - ie - you can allow 3
unsucessful logins, then have a lockout period of 30 minutes or whatever
(you specify both). I haven't actually verified this - it is in the docs but
it doesn't work under WinXP - after much searching I found that this feature
will only work on Win2003 server and I haven't installed the Beta on a
server yet.
<<I have port 1433 and 1434 open also going thru a Virtual IP, so far no
attacks.>>
Depending on how you are looking you may not notice them. Some drones are
just dialup - you would have a hard time seeing the once per second login
attempt on the bandwidth. Some drones are on high speed connections - will
give you a straight line on your bandwidth (30 or more connection attempts
per second). To see if anyone is trying, run the SQL Profiler and setup a
trace to record unsuccessful logins. They won't show up in your normal
events log. If 1433 is open to the Internet you can almost bet someone is
trying to get in during some parts of the day. Not sure why you would want
udp 1434 open - make them work a little harder <g>.
Russ Stevens|||Unfortunately it isn't a bug (where bug = coding error) in SQL Server 2000.
It isn't even a design flaw in the classic sense. It is a missing feature
set dating back to the original Sybase decisions made 20 years ago.
Microsoft's fix was to add integrated (aka Windows) security and push people
not to use the legacy SQL Server security stuff at all. That fixes the
problem. But despite Microsoft's desire to do away with the legacy security
stuff it is still heavily used. Partially for bad reasons (like, it just
being easier to embed a password in the application) and partially for good
reasons (like, we have to access it from a Unix system). So for SQL Server
2005 they are finally acknowleding that and re-working the Sybase-derived
stuff to use the full set of Windows password protections. But I doubt it
is something of a scope that it could be easily (mostly meaning safely and
reliably) backported into a SQL Server 2000 service pack. Not impossible of
course, but just well beyond the scope of a service pack.
Personally, I would NOT put a SQL Server 2000 directly on the Internet.
There are reasons beyond the password security issues that make me queasy
(not that I know of any specific vulnerability). The better way to enable
your users to access SQL Server remotely is to have them VPN in. That is
yet another reason Microsoft wasn't incented to enhance the legacy password
stuff earlier.
At a minimum you should use a non-standard port for your SQL Server if it is
going to be on the net. That should minimize the attacks (since I imagine
most of them are built on the premise that SQL Server uses 1433).
Hal Berenson, President
PredictableIT
Phone: 805-212-1025 ext 101
hberenson@.predictableit.com
Helpdesk: 805-212-1024 ext 1
"Russell Stevens" <rustyprogrammer@.online.nospam> wrote in message
news:um$43caqFHA.3524@.tk2msftngp13.phx.gbl...
> Microsoft refuses to fix this glaring problem in SQL 2000. You can use a
> port monitor to get the IP numbers then block them with a firewall or use
> IPsec to block the IP numbers. It is a never ending job as new drones will
> be attacking every day.
> Microsoft's reply is that you shouldn't be doing this. Of course, they
> will be glad to sell you a copy of SQL Server 2005 that does fix this
> (non) problem.
> With a strong password, the attackers will never be successful, but they
> can eat up a lot of bandwidth trying.
> Russ Stevens
>|||Hal,
<<It is a missing feature
set dating back to the original Sybase decisions made 20 years ago.
Microsoft's fix was to add integrated (aka Windows) security and push people
not to use the legacy SQL Server security stuff at all>>
Its refreshing to hear someone NOT say "SQL server was not designed to allow
open Internet access". As you mention, it was designed exactly for that
originally. Of course, this is further compounded by the fact that you can't
change the sa account. Microsoft recommends you rename the Administrator
account on its servers so that a hacker needs to guess both the user name
and a password. Given that the sa account is fixed, the hacker only needs to
guess a password. Then, on top of that, for years, the default password for
the sa account was an empty string. So hackers knew the login name and knew
the password for lots of SQL servers without having to do anything. It is
now a little harder as they try to crack the password using a dictionary
attack. Put a new SQL server online, and the hacks will start within an
hour.
I think Microsoft could easily fix this in a service pack if they wanted to.
They already have the necessary code for tracking unsuccessful logins (in
Profiler). They don't need to tie it in to group policy, etc. to fix this in
SQL 2000 - after x unsuccessful tries, block out y for z time and allow the
sa account to be renamed. Using another port doesn't help much - the hackers
can easily determine the SQL port.
Sure, the SQL 2005 way is the best way to do it (tied in to the OS), but
anyway you do it is better than the SQL 2000 way. Just imagine the amount of
Internet bandwidth that would then become available for something useful
<g>.
Russ Stevens|||Allow the SA account to be renamed in a service pack? You are mad. That
would break the entire product and require many thousands of lines of code
to be changed (not to mention all the customer apps that would be broken).
Put in a hard coded delay (z) after x failed login attempts for a particular
account (y), with no user interface for controlling x or z? That might be
reasonable. An even easier change would be to just insert a timeout-1
second delay before responding to a TDS Login packet that contained an
invalid password. That would effectively kill the automated attacks without
breaking anything (important). Unfortunately, it is likely to be a long
time until the next SQL Server 2000 Service Pack and that will (I'm
guessing) be little more than a hotfix rollup. So we've probably missed the
boat on doing anything for SQL Server 2000.
Hal Berenson, President
PredictableIT
Phone: 805-212-1025 ext 101
hberenson@.predictableit.com
Helpdesk: 805-212-1024 ext 1
"Russell Stevens" <rustyprogrammer@.online.nospam> wrote in message
news:u7sJiP%23qFHA.3600@.TK2MSFTNGP10.phx.gbl...
> Hal,
> <<It is a missing feature
> set dating back to the original Sybase decisions made 20 years ago.
> Microsoft's fix was to add integrated (aka Windows) security and push
> people
> not to use the legacy SQL Server security stuff at all>>
> Its refreshing to hear someone NOT say "SQL server was not designed to
> allow open Internet access". As you mention, it was designed exactly for
> that originally. Of course, this is further compounded by the fact that
> you can't change the sa account. Microsoft recommends you rename the
> Administrator account on its servers so that a hacker needs to guess both
> the user name and a password. Given that the sa account is fixed, the
> hacker only needs to guess a password. Then, on top of that, for years,
> the default password for the sa account was an empty string. So hackers
> knew the login name and knew the password for lots of SQL servers without
> having to do anything. It is now a little harder as they try to crack the
> password using a dictionary attack. Put a new SQL server online, and the
> hacks will start within an hour.
> I think Microsoft could easily fix this in a service pack if they wanted
> to. They already have the necessary code for tracking unsuccessful logins
> (in Profiler). They don't need to tie it in to group policy, etc. to fix
> this in SQL 2000 - after x unsuccessful tries, block out y for z time and
> allow the sa account to be renamed. Using another port doesn't help much -
> the hackers can easily determine the SQL port.
> Sure, the SQL 2005 way is the best way to do it (tied in to the OS), but
> anyway you do it is better than the SQL 2000 way. Just imagine the amount
> of Internet bandwidth that would then become available for something
> useful <g>.
> Russ Stevens
>|||Hal,
<<Allow the SA account to be renamed in a service pack? You are mad>>
No - the SP doesn't rename it, it gives the SQL admin the ability to change
it. If he has apps that use it, then he can fix them first or leave as is.
<<Unfortunately, it is likely to be a long
time until the next SQL Server 2000 Service Pack and that will (I'm
guessing) be little more than a hotfix rollup. So we've probably missed the
boat on doing anything for SQL Server 2000.>>
We have been missing the boat for many years - Microsoft just refuses to fix
it (this is not a new issue <g> ).
Thanks
Russ Stevens|||On Mon, 29 Aug 2005 08:22:51 -0400, Russell Stevens wrote:

> <<Allow the SA account to be renamed in a service pack? You are mad>>
> No - the SP doesn't rename it, it gives the SQL admin the ability to chang
e
> it. If he has apps that use it, then he can fix them first or leave as is.
There are many many parts *internal* to SQL server that depend on the sa
account being named sa. A service pack that changes them all to tolerate a
renamed sa account is a dangerous thing to do.|||I've been programming for 20+ years and to me there are a number of
inexpensive solutions to this problem that Microsoft could deploy, but they
have delibertly choosen not to for whatever motive. The fact that no
Micrsoft MVP has responded to this post as I have seen in most other posts,
further backs this opinion.
Is there a Microsft MVP out there willing to touch this issue?
"Ross Presser" wrote:

> On Mon, 29 Aug 2005 08:22:51 -0400, Russell Stevens wrote:
>
> There are many many parts *internal* to SQL server that depend on the sa
> account being named sa. A service pack that changes them all to tolerate
a
> renamed sa account is a dangerous thing to do.
>