Showing posts with label exception. Show all posts
Showing posts with label exception. Show all posts

Wednesday, March 7, 2012

error-Line 1: Incorrect syntax near =

hi,

i got this error when i run app.

-----
Line 1: Incorrect syntax near '='.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Data.SqlClient.SqlException: Line 1: Incorrect syntax near '='.

Source Error:

Line 40: Dim adpt As New SqlDataAdapter("SELECT * FROM SMS_student_class_master WHERE" & _
Line 41: "stud_id=" & sid, con)
Line 42: adpt.Fill(ds, "SMS_student_class_master")
Line 43: txt.Text = ds.Tables.Item("roll_no").ToString
Line 44: con.Close()

Source File: c:\inetpub\wwwroot\aspnet\sms\assignment_d.aspx.vb Line: 42
---

what should i do?
anyone have any idea?
plz give solution.
it's urgent.

thanks in advanceThis error indicates that there is an error in your sql statement. It looks like you do not have a space after your WHERE keyword.

hope this does the trick,
sivilian|||I think you have forgotten to put a space after WHERE and before stud_id

According to your string that you have formatted in Line 40 and 41, the sql string that will comes up will be like so

SELECT * FROM SMS_student_class_master WHEREstud_id=123

You should have put the string like below:

Dim adpt As New SqlDataAdapter("SELECT * FROM SMS_student_class_master WHERE " & _
"stud_id=" & sid, con)

Sunday, February 26, 2012

Error:Cannot resolve collation conflict for equal to operation.

Exception information:System.Data.SqlClient.SqlException: Cannot resolve collation conflict for equal to operation.
Who can tell me how to resolve this problem?
ThxIs this an error you've seen here on the ASP.NET Forums? (After all, you've posted this message in the forum dedicated to ASP.NET Forum bugs and discussions.)

Or, is this an error in your own application? If so, I will move this thread into theSQL Server and MSDE forum.|||Maybe I made a mistake.(I just met this error in my own server with asp.net environment)|||You've got mixed collations, this typically occurs when your underlying tables collation doesn't match the servers default collation. You need to specify the collation you want to use in the query. Look up COLLATE and DATABASE_DEFAULT.

It's also a common gotcha if you're using table vars, for the same reason, the same "COLLATE database_default" does the trick.

Friday, February 24, 2012

Error:14234

Hi,

I am trying to schedule an SSIS package in SQL Server 2005.

I am getting an error as follows:

An exception occured while executing a TRansact-SQL statement or batch.

(Microsoft.SqlServer.ConnectionInfo)

The specified '@.subsytem' is invalid (valid values are returned by sp_enum_sqlagent_subsytems).

(Microsoft SQL Server, Error:14234)

I dont know how to resolve this. I am a little bit new to the SQL Server 2005.

Please help asap.

Thanks

I don't think you've installed SSIS on that machine. Grab the CDs and install SSIS.|||Hey Thanks a lot...it worked

Friday, February 17, 2012

Error: System.Runtime.InteropServices.COMException ...

Error: System.Runtime.InteropServices.COMException (0x80040428): Exception from HRESULT: 0x80040428 at DTS.PackageClass.Execute() at Microsoft.SqlServer.Dts.Tasks.Exec80PackageTask.Exec80PackageTask.ExecuteThread()

Can anyone tell what caused this error when I tried to run the DTS package from my SSIS package ?

Thanks.

Steve

I had the same problem....drove me batty. Packages run fine using Execute Package utility in SSMS - but fail when running as a scheduled job, or called from within a Stored Procedure - failed every time.

I found my particular issue was not permission, per say, but rather the Exception file, I was referencing in the Data Driven Query task - which kept failing. Once I removed the Exception File, everything runs fine.

|||

I have had a similar problem running a SQL2000 DTS job from within an SSIS package. The strange thing I found that on the production server, it would readily run the job, yet a similarly created DTS on the development servers failed.

What was the "Exception file" that you had to remove?

|||

If you trust the internal logic of your package, then an error condition - especially from an Agent job - usually points to the package's interaction with external resources; in particular, to permissions issues. That's probably why no longer trying to write to an exception file solved the problem for the other gentleman. Check the package's use of database connections and file system resources, and determine whether the account under which it's executing does indeed have the required rights to connect, to read and write, etc.

Here's the Agent Job kb article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;918760

-Doug

|||

I have rewrote the DTS package into a stored procedure that

1) Truncates the target tables

2) Copy the data from the source on another database to the target tables

3) Backs up the target database.

Now the account that would not run the DTS package runs a stored procedure successfully!

Error: System.Runtime.InteropServices.COMException ...

Error: System.Runtime.InteropServices.COMException (0x80040428): Exception from HRESULT: 0x80040428 at DTS.PackageClass.Execute() at Microsoft.SqlServer.Dts.Tasks.Exec80PackageTask.Exec80PackageTask.ExecuteThread()

Can anyone tell what caused this error when I tried to run the DTS package from my SSIS package ?

Thanks.

Steve

I had the same problem....drove me batty. Packages run fine using Execute Package utility in SSMS - but fail when running as a scheduled job, or called from within a Stored Procedure - failed every time.

I found my particular issue was not permission, per say, but rather the Exception file, I was referencing in the Data Driven Query task - which kept failing. Once I removed the Exception File, everything runs fine.

|||

I have had a similar problem running a SQL2000 DTS job from within an SSIS package. The strange thing I found that on the production server, it would readily run the job, yet a similarly created DTS on the development servers failed.

What was the "Exception file" that you had to remove?

|||

If you trust the internal logic of your package, then an error condition - especially from an Agent job - usually points to the package's interaction with external resources; in particular, to permissions issues. That's probably why no longer trying to write to an exception file solved the problem for the other gentleman. Check the package's use of database connections and file system resources, and determine whether the account under which it's executing does indeed have the required rights to connect, to read and write, etc.

Here's the Agent Job kb article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;918760

-Doug

|||

I have rewrote the DTS package into a stored procedure that

1) Truncates the target tables

2) Copy the data from the source on another database to the target tables

3) Backs up the target database.

Now the account that would not run the DTS package runs a stored procedure successfully!

Error: System.Runtime.InteropServices.COMException ...

Error: System.Runtime.InteropServices.COMException (0x80040428): Exception from HRESULT: 0x80040428 at DTS.PackageClass.Execute() at Microsoft.SqlServer.Dts.Tasks.Exec80PackageTask.Exec80PackageTask.ExecuteThread()

Can anyone tell what caused this error when I tried to run the DTS package from my SSIS package ?

Thanks.

Steve

I had the same problem....drove me batty. Packages run fine using Execute Package utility in SSMS - but fail when running as a scheduled job, or called from within a Stored Procedure - failed every time.

I found my particular issue was not permission, per say, but rather the Exception file, I was referencing in the Data Driven Query task - which kept failing. Once I removed the Exception File, everything runs fine.

|||

I have had a similar problem running a SQL2000 DTS job from within an SSIS package. The strange thing I found that on the production server, it would readily run the job, yet a similarly created DTS on the development servers failed.

What was the "Exception file" that you had to remove?

|||

If you trust the internal logic of your package, then an error condition - especially from an Agent job - usually points to the package's interaction with external resources; in particular, to permissions issues. That's probably why no longer trying to write to an exception file solved the problem for the other gentleman. Check the package's use of database connections and file system resources, and determine whether the account under which it's executing does indeed have the required rights to connect, to read and write, etc.

Here's the Agent Job kb article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;918760

-Doug

|||

I have rewrote the DTS package into a stored procedure that

1) Truncates the target tables

2) Copy the data from the source on another database to the target tables

3) Backs up the target database.

Now the account that would not run the DTS package runs a stored procedure successfully!

Error: System.Runtime.InteropServices.COMException ...

Error: System.Runtime.InteropServices.COMException (0x80040428): Exception from HRESULT: 0x80040428 at DTS.PackageClass.Execute() at Microsoft.SqlServer.Dts.Tasks.Exec80PackageTask.Exec80PackageTask.ExecuteThread()

Can anyone tell what caused this error when I tried to run the DTS package from my SSIS package ?

Thanks.

Steve

I had the same problem....drove me batty. Packages run fine using Execute Package utility in SSMS - but fail when running as a scheduled job, or called from within a Stored Procedure - failed every time.

I found my particular issue was not permission, per say, but rather the Exception file, I was referencing in the Data Driven Query task - which kept failing. Once I removed the Exception File, everything runs fine.

|||

I have had a similar problem running a SQL2000 DTS job from within an SSIS package. The strange thing I found that on the production server, it would readily run the job, yet a similarly created DTS on the development servers failed.

What was the "Exception file" that you had to remove?

|||

If you trust the internal logic of your package, then an error condition - especially from an Agent job - usually points to the package's interaction with external resources; in particular, to permissions issues. That's probably why no longer trying to write to an exception file solved the problem for the other gentleman. Check the package's use of database connections and file system resources, and determine whether the account under which it's executing does indeed have the required rights to connect, to read and write, etc.

Here's the Agent Job kb article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;918760

-Doug

|||

I have rewrote the DTS package into a stored procedure that

1) Truncates the target tables

2) Copy the data from the source on another database to the target tables

3) Backs up the target database.

Now the account that would not run the DTS package runs a stored procedure successfully!

ERROR: System.OutOfMemoryException

How should I resolve the following error message when running report?
ERROR:
Exception of type 'System.OutOfMemoryException' was thrownBuy more RAM ¬¬
No, I'm kidding. Well, what are you exactly doing? Are you running a report
that accesses many tables or tables with many rows?|||What a great sense of humor!
However, I am just running a report via Report Manager.
http://reportserv/reports
TABLE ROWS below:
6,683
QUERY below:
SELECT Lists_Members.LSTM_Lists_ID, Lists_Members.LSTM_Group,
List_Codes_Table.LIST_Name, Lists_Members.LSTM_Name_ID
FROM Lists_Members AS Lists_Members INNER JOIN
List_Codes_Table AS List_Codes_Table ON
Lists_Members.LSTM_Lists_ID = List_Codes_Table.LIST_Id
GROUP BY Lists_Members.LSTM_Lists_ID, Lists_Members.LSTM_Group,
List_Codes_Table.LIST_Name, Lists_Members.LSTM_Name_ID
ORDER BY Lists_Members.LSTM_Lists_ID, Lists_Members.LSTM_Group
"F. Dwarf" wrote:
> Buy more RAM ¬¬
> No, I'm kidding. Well, what are you exactly doing? Are you running a report
> that accesses many tables or tables with many rows?|||Well, I'm still puzzled. I don't figure out what could be the problem