Showing posts with label writing. Show all posts
Showing posts with label writing. Show all posts

Friday, March 9, 2012

Error. My aspx file cant access server to connect to database

Hi,

I am writing my first aspx file to connect to a standalone SQL Server which is separated from the IIS webserver. The code is

<HTML>
<HEAD>
<TITLE>Store Locator</TITLE>
<script runat="server">
Sub Page_Load(ByVal Sender as Object, ByVal E as EventArgs)
if Not IsPostBack Then
Dim DBConn as OleDbConnection
Dim DBCommand As OleDbDataAdapter
Dim DSPageData as New DataSet
DBConn = New OleDbConnection("Provider=sqloledb;" _
& "server=dailyplanet;" _
& "Initial Catalog=JAVSTORE;" _
& "User Id=javtrader;" _
& "Password=rage123;")
DBCommand = New OleDbDataAdapter _
("Select * " _
& "From JAVInventory " _
& "Where ID > ((Select COUNT(ID) " _
& "From JAVInventory ) - 100)" _
& "Order By ID DESC", DBConn)
DBCommand.Fill(DSPageData, _
"RecentJAVs")
' ddlZipCode.DataSource = _
' DSPageData.Tables("RecentJAVs").DefaultView
' ddlZipCode.DataBind()
End If
End Sub

I used Visual .Net and Web Matrix and was able to connect to the sql server with the Data Connection to view the tables. However, when I use IIS or the Visual .Net debugger to run the aspx file, it get the following error.. please help..

Server Error in '/javtrade' Application.
------------------------

[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
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.OleDb.OleDbException: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

Source Error:

Line 21: & "From JAVInventory ) - 100)" _
Line 22: & "Order By ID DESC", DBConn)
Line 23: DBCommand.Fill(DSPageData, _
Line 24: "RecentJAVs")
Line 25: ' ddlZipCode.DataSource = _

Source File: c:\inetpub\wwwroot\javtrade\management.aspx Line: 23

Stack Trace:

[OleDbException (0x80004005): [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.]
System.Data.OleDb.OleDbConnection.ProcessResults(Int32 hr)
System.Data.OleDb.OleDbConnection.InitializeProvider()
System.Data.OleDb.OleDbConnection.Open()
System.Data.Common.DbDataAdapter.QuietOpen(IDbConnection connection, ConnectionState& originalState) +44
System.Data.Common.DbDataAdapter.FillFromCommand(Object data, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) +304
System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) +77
System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) +36
ASP.management_aspx.Page_Load(Object Sender, EventArgs E) in c:\inetpub\wwwroot\javtrade\management.aspx:23
System.Web.UI.Control.OnLoad(EventArgs e) +67
System.Web.UI.Control.LoadRecursive() +35
System.Web.UI.Page.ProcessRequestMain() +731FYI, when using sql server it is better to use the sql namespace over the oledb. I assume you have a connection string in your web.config file. This can be formed in two ways, one using a trusted connection, or the other being uid=; and pwd=; the login and password for sql respectively. Either version of the connection string must include the server name, which is localhost, 127.0.0.1 if on the localmachine or the actual name or ip of the server.

Error writing data to same destination in single data flow

I am getting the following error running a data flow that splits the input data into multiple streams and writes the results of each stream to the same destination table:

"This operation conflicts with another pending operation on this transaction. The operation failed."

The flow starts with a single source table with one row per student and multiple scores for that student. It does a few lookups and then splits the stream (using Multicast) in several layers, ultimately generating 25 destinations (one for each score to be recorded), all going to the same table (like a fact table). This all is running under a transaction at the package level, which is distributed to a separate machine.

Apparently, I cannot have all of these streams inserting data into the same table at one time. I don't understand why not. In an OLTP system, many transactions are inserting records into the same table at once. Why can't I do that within the same transaction?

I suppose I can use a UnionAll to join them back together before writing to a single destination, but that seems like an unnecessary waste and clutters the flow. Can anyone offer a different solution or a reason why this fails in the first place?

Thanks in advance.

What type of load are you using? Fast load with table lock? Certainly you will need to take off table lock, and maybe drop the fast load too.

An OLTP system is not doing a bulk load, it is doing nice and slow atomic transactions.

I also don't see what is wrong with the Union All transform. If you can get the current design working, then I think you should also try the union, and let us know which is faster, as that would be the real reason to choose one over the other, not good looks!

Re-reading this I see mention of a distributed transaction which matches the error better. Try using speparate connections for each destination. If the only reason for using the transaction is to ensure integrity accross the multiple destinations, then this would make me think of union even more as a distributed transaction can add a fair overhead.

|||

Thanks for the reply and the suggestions. Sorry for the delay in a follow-up, the automated alert for replies didn't work for me and I didn't know there was a reply.

I have since rewritten it to use the UnionAll task and it works. It's not so much an issue of how it looks, rather the trouble required to build it and maintain it. The current version of that task does not make it easy to distinguish which input is which so you can set the appropriate columns correctly. And if you should need to disconnect one stream from the UnionAll and reconnect it, the relative position of that stream moves and gets renamed. It's just a hassle to get right. Elegance in appearance is often times a clue to an elegant technical solution. Not always, but I'm a believer in a good "looking" solution.

You have a good suggestion about turning off the table lock and maybe the fast load option. I hadn't thought of that before I rewrote it. If I get a chance, I'll try the original approach and see if I can get it working.

The need for a transaction is to make sure all the data is loaded or none of it. If some part of it should fail, I want to rerun the entire package to load all the data again. This data flow isn't the only one in the package.

Thanks again.

Error writing data to same destination in single data flow

I am getting the following error running a data flow that splits the input data into multiple streams and writes the results of each stream to the same destination table:

"This operation conflicts with another pending operation on this transaction. The operation failed."

The flow starts with a single source table with one row per student and multiple scores for that student. It does a few lookups and then splits the stream (using Multicast) in several layers, ultimately generating 25 destinations (one for each score to be recorded), all going to the same table (like a fact table). This all is running under a transaction at the package level, which is distributed to a separate machine.

Apparently, I cannot have all of these streams inserting data into the same table at one time. I don't understand why not. In an OLTP system, many transactions are inserting records into the same table at once. Why can't I do that within the same transaction?

I suppose I can use a UnionAll to join them back together before writing to a single destination, but that seems like an unnecessary waste and clutters the flow. Can anyone offer a different solution or a reason why this fails in the first place?

Thanks in advance.

What type of load are you using? Fast load with table lock? Certainly you will need to take off table lock, and maybe drop the fast load too.

An OLTP system is not doing a bulk load, it is doing nice and slow atomic transactions.

I also don't see what is wrong with the Union All transform. If you can get the current design working, then I think you should also try the union, and let us know which is faster, as that would be the real reason to choose one over the other, not good looks!

Re-reading this I see mention of a distributed transaction which matches the error better. Try using speparate connections for each destination. If the only reason for using the transaction is to ensure integrity accross the multiple destinations, then this would make me think of union even more as a distributed transaction can add a fair overhead.

|||

Thanks for the reply and the suggestions. Sorry for the delay in a follow-up, the automated alert for replies didn't work for me and I didn't know there was a reply.

I have since rewritten it to use the UnionAll task and it works. It's not so much an issue of how it looks, rather the trouble required to build it and maintain it. The current version of that task does not make it easy to distinguish which input is which so you can set the appropriate columns correctly. And if you should need to disconnect one stream from the UnionAll and reconnect it, the relative position of that stream moves and gets renamed. It's just a hassle to get right. Elegance in appearance is often times a clue to an elegant technical solution. Not always, but I'm a believer in a good "looking" solution.

You have a good suggestion about turning off the table lock and maybe the fast load option. I hadn't thought of that before I rewrote it. If I get a chance, I'll try the original approach and see if I can get it working.

The need for a transaction is to make sure all the data is loaded or none of it. If some part of it should fail, I want to rerun the entire package to load all the data again. This data flow isn't the only one in the package.

Thanks again.

Error writing binary data

Dear all,
we run a SQL Server 2000 SE 8.00.534 SP2 on a 2 CPU server.
We have three similar databases, which all contain a table to store binaries
as base64-Text.
From time to time we face a problem writing in one of this tables. The
requests get a timeout.
Its always the same table in the same database. The other tables never
caused any problem.
Reading access ist no problem, but writing doesn't work.
We can fix the problem by copying the data in a new table an rename them
that the new table replaces the old one. Sometimes the problem ist solved
when we add a new index (doesn't matter which column) and save the table.
You can't see any difference between the the table in the relevant database
and the other ones.
Even a restart of the whole machine doesn't solve the problem, so that locks
shouldn't be the cause.
Any tips?
Greeting from Germany
Matthias MerzHi
There are a significant number of changes between the version you are
running and the current version (2187) so you may want to review the KB
article to see if there is anything that may have fixed this
http://www.aspfaq.com/sql2000builds.asp
If you are getting any error messages in the SQL Server log or the Windows
Event log will help.
You don't say if dropping all indexes helps!!!
John
"Matthias Merz" wrote:
> Dear all,
> we run a SQL Server 2000 SE 8.00.534 SP2 on a 2 CPU server.
> We have three similar databases, which all contain a table to store binaries
> as base64-Text.
> From time to time we face a problem writing in one of this tables. The
> requests get a timeout.
> Its always the same table in the same database. The other tables never
> caused any problem.
> Reading access ist no problem, but writing doesn't work.
> We can fix the problem by copying the data in a new table an rename them
> that the new table replaces the old one. Sometimes the problem ist solved
> when we add a new index (doesn't matter which column) and save the table.
> You can't see any difference between the the table in the relevant database
> and the other ones.
> Even a restart of the whole machine doesn't solve the problem, so that locks
> shouldn't be the cause.
> Any tips?
> Greeting from Germany
> Matthias Merz
>
>

Error writing binary data

Dear all,
we run a SQL Server 2000 SE 8.00.534 SP2 on a 2 CPU server.
We have three similar databases, which all contain a table to store binaries
as base64-Text.
From time to time we face a problem writing in one of this tables. The
requests get a timeout.
Its always the same table in the same database. The other tables never
caused any problem.
Reading access ist no problem, but writing doesn't work.
We can fix the problem by copying the data in a new table an rename them
that the new table replaces the old one. Sometimes the problem ist solved
when we add a new index (doesn't matter which column) and save the table.
You can't see any difference between the the table in the relevant database
and the other ones.
Even a restart of the whole machine doesn't solve the problem, so that locks
shouldn't be the cause.
Any tips?
Greeting from Germany
Matthias MerzHi
There are a significant number of changes between the version you are
running and the current version (2187) so you may want to review the KB
article to see if there is anything that may have fixed this
http://www.aspfaq.com/sql2000builds.asp
If you are getting any error messages in the SQL Server log or the Windows
Event log will help.
You don't say if dropping all indexes helps!!!
John
"Matthias Merz" wrote:

> Dear all,
> we run a SQL Server 2000 SE 8.00.534 SP2 on a 2 CPU server.
> We have three similar databases, which all contain a table to store binari
es
> as base64-Text.
> From time to time we face a problem writing in one of this tables. The
> requests get a timeout.
> Its always the same table in the same database. The other tables never
> caused any problem.
> Reading access ist no problem, but writing doesn't work.
> We can fix the problem by copying the data in a new table an rename them
> that the new table replaces the old one. Sometimes the problem ist solved
> when we add a new index (doesn't matter which column) and save the table.
> You can't see any difference between the the table in the relevant databas
e
> and the other ones.
> Even a restart of the whole machine doesn't solve the problem, so that loc
ks
> shouldn't be the cause.
> Any tips?
> Greeting from Germany
> Matthias Merz
>
>