Showing posts with label asp. Show all posts
Showing posts with label asp. Show all posts

Wednesday, March 21, 2012

Postback causing Database Transactions to Replay

Hey,

I hope someone can quickly tell me what I am obviously missing for this weird problem.

To give a general picture, I have an ASP.net webpage that allows users to select values from several dropdown menus and click an add button which formats and concatenates the items together into a listbox. After the listbox has been populated the users have the option to save the items via a save button.


The save button parses each item in the listbox to basically de-code the concantenated values and subsequently inserts them into a table residing on a backend MSSQL 2005 database.

PROBLEM:

In the process of testing the application, I noted this strange behavior. If I use the webpage to insert the values, go to the table where the values are stored and delete the rows; Upon a refresh of the web page the same actions seem to be getting replayed and the items are again inserted into the table.

Naturally, what I'd really like would be for the page to refresh and show that the items aren't any longer there and not the other way around.

If the code that performed the insert was residing in a component that was set for postback I'd expect this type of behavior but its in the Save buttons on_click event. I have tried practically everything in effort of targeting the problem but not having much luck with it.

Is this behavior practical and expected in ASP.net or has anyone ever heard of anything similar? I have never encountered this type of problem before and was hoping someone could provide some clues for resolving it. If more information is required I'd be happy to supply it. Hopefully, there's a simple explanation that I am simply unaware since I haven't experienced anything like this before.

Anybody got any ideas?

Thanks.

Do you know about the page method IsPostback?

that is,

in page_load (or whatever)

if (!Page.IsPostBack)
{

}

|||

Hi Peter,

Yes, I am familiar with the IsPostBack method and I realize that any code placed inside of the if (!Page.IsPostBack) {} will typically only be executed upon the initial load of the page if that's where the condition is placed. I explored the possibility of overlooking that somewhere in my code and also experimented by placing that condition a various points in the code starting with the obvious, "the save_onClick event" but results are either the data doesn't get inserted into the database or it will insert the data and persist manipulation of the data in the database.

As I presently have it setup, on the btnSave_OnClick event; the data is inserted into the database table by looping through all the values in one listbox, then that listbox is cleared of all items and another listbox is populated with the inserted data variables through an active connection to the database and a select all statement. The intent was to allow the users to see the data they just inserted into the table. I suppose I could remove this feature and resolve the problem but I'd much rather identify why its happening and come up with a more viable solution.

I am open to any alternative solutions as well if the outcome will produce the desired results.

Any other thoughts?Smile

|||I'm having trouble following where the problem might be but I'm sure it's solvable. could be a databind problem? an event order problem? maybe want to think about using page_prerender event. Sorry can't be much more help. don't give up!|||

Thanks for trying Peter.

I have managed to target the specific problem now. Debugging the app shows me the issue is that (refreshing or reloading) the page, is causing the on_click event of the save button to be fired. So it appears I was right on target with the description of the problem as the inserts are actually being replayed to the database upon a refresh of the page.

So what I need to determine is what can be done to prevent previous events of the button from being retriggered on a refresh but allowed on a normal postback (if there is any such animal).

Obviously implementing the !Page.IsPostback method in the block of code for the button_click event won't work because the records would never get inserted and I can't place the button_click event inside of the page_prerender event either.

There has got to be a simple method of preventing this from happening. Maybe some way to programmatically distinguish a page postback from a page reload would be an option?

Anyway, I'll keep posting in other forums to see if I can get some additional feedback. I simply can't believe that this type of thing is only new to me.

Thanks again.Yes

|||can you post a simple example that demonstrates your problem?|||

Sure.

I am using a Standard Button, a Listbox, and C# with ASP.net. So far I have examined other methods that may give me what I need in terms of behavior including enableViewState and a few others but I can't seem to control the _Click event from replaying the previous action upon reload of the page.

 
1//Save button iterates through the listbox and acquires the data added by the user2protected void btnSave_Click(object sender, EventArgs e)3 {4 String adUserInsert ="";56try7 {8for (x = 0; x < lstUser.Items.Count; x++)9 {10 adUserInsert = lstUser.Items[x].Text.ToString();11 insertRecords(adUserInsert);12 lstInsertedUser.Items.Add(adUserInsert);13 }14 }15catch16 {17//Error Trap18 }19 }2021//This function inserts the record into the database22private void insertRecords(String adUserInsert)23 {2425try26 {27 String sqlConnString ="Provider=SQLNCLI;Server=TESTSERV;Database=Users_db;Uid=sa;Pwd=p@.sswrd25;";28 String sqlQuery ="INSERT INTO Users_db VALUES('" + adUserInsert +"')";29 OleDbConnection sqlConn =new OleDbConnection(sqlConnString);30 OleDbCommand sqlCommand =new OleDbCommand(sqlQuery, sqlConn);31 sqlConn.Open();32 sqlCommand.ExecuteNonQuery();33//Close the DB connection after use34 sqlConn.Close();35 }36catch37 {38//Error Trap39 }40 }

Tuesday, March 20, 2012

Post method in ASP stops working

I am having an issue on a windows 2003 box where I run a report to a new
window, and I do a request.form to get all my parameters. The first time I
run a report to a new window I am prompted for the windows user name and
password. Once I enter in the login info my report runs fine. Then when I try
to run another report to a new window the request.form doesn't work to pull
things in from my form. Everything is blank, so I get error messages. Another
report will not run until I shutdown IE restart IE log back into my website
and run the report.
My redirect string is
http://Session('sServer')/ReportServer?/Session("sProjectCode")/sReport &
"&rs:Command=render&rs:Format=HTML4.0&rc:Paramaters=False"
Can anyone tell me why the post method or Request.form will only work once
and then I have to restart IE. Again I am opening the report in a new window.
--
Thanks,
CraigI fixed this by going into IIS and going into the properties on the Reports
and ReportServer Virtual directories and under Directory security enabling
anonymous access.
"Craig" wrote:
> I am having an issue on a windows 2003 box where I run a report to a new
> window, and I do a request.form to get all my parameters. The first time I
> run a report to a new window I am prompted for the windows user name and
> password. Once I enter in the login info my report runs fine. Then when I try
> to run another report to a new window the request.form doesn't work to pull
> things in from my form. Everything is blank, so I get error messages. Another
> report will not run until I shutdown IE restart IE log back into my website
> and run the report.
> My redirect string is
> http://Session('sServer')/ReportServer?/Session("sProjectCode")/sReport &
> "&rs:Command=render&rs:Format=HTML4.0&rc:Paramaters=False"
> Can anyone tell me why the post method or Request.form will only work once
> and then I have to restart IE. Again I am opening the report in a new window.
> --
> Thanks,
> Craig

Monday, March 12, 2012

Possible To Start Agent Job from ASP or asp.net

I have a long running process that i would like to have started via a web
application. I suppose I have a few options and im not sure if #1 is
possible.
#1 - Start A Job via ASP or ASP.NET
#2 - Set a Flag that a job checks when it runs on a repeating schedule so
it will take action instead of just repeating again next time the schedule
hits.
#3 - Make sure all is ready for the job which occurs at a known time (a bad
idea)
Anyone know if #1 has a solution?You can start a sql job by calling this stored procedure.
e.g.
exec msdb..sp_start_job 'your_job'
-oj
"Erik Jensen" <ErikJensen@.discussions.microsoft.com> wrote in message
news:D1D61D84-36C5-40C9-8990-B4D8D11D2677@.microsoft.com...
>I have a long running process that i would like to have started via a web
> application. I suppose I have a few options and im not sure if #1 is
> possible.
> #1 - Start A Job via ASP or ASP.NET
> #2 - Set a Flag that a job checks when it runs on a repeating schedule so
> it will take action instead of just repeating again next time the schedule
> hits.
> #3 - Make sure all is ready for the job which occurs at a known time (a
> bad
> idea)
> Anyone know if #1 has a solution?
>

Saturday, February 25, 2012

possible Scope_Identity() problem

I have an ASP.NET application with a SQL Server 2000 backend, where two
pages fire off two different stored procedures. Each stored procedure
creates a new record in a particular table then uses Scope_Identity() to get
the id of the newly created record for adding it to a link table. The
problem I'm seeing appears to be Scope_Identity() behaving as thought it
were @.@.IDENTITY, i.e. on the occasion when both procedures are fired at once
(different machines and browsers, not that it should matter), one procedure
appears to get the id of the record created by the other and essentially
steal its record.
Has anyone come across anything like this before?
thanks in advance,
--
jo inferisHi
Do you have code to reproduce this issue?
I only way I could think this happens is if both SP's are executed on the
same connection (which is unlikely).
Regards
Mike
"Jo Inferis" wrote:

> I have an ASP.NET application with a SQL Server 2000 backend, where two
> pages fire off two different stored procedures. Each stored procedure
> creates a new record in a particular table then uses Scope_Identity() to g
et
> the id of the newly created record for adding it to a link table. The
> problem I'm seeing appears to be Scope_Identity() behaving as thought it
> were @.@.IDENTITY, i.e. on the occasion when both procedures are fired at on
ce
> (different machines and browsers, not that it should matter), one procedur
e
> appears to get the id of the record created by the other and essentially
> steal its record.
> Has anyone come across anything like this before?
> thanks in advance,
> --
> jo inferis
>
>|||Hi Jo,
Use IDENT_CURRENT('table_name') to get the Identity value. Because
IDENT_CURRENT returns the last identity value generated for a specific table
in any session and any scope.
@.@.IDENTITY returns the last identity value generated for any table in the
current session, across all scopes.
SCOPE_IDENTITY returns the last identity value generated for any table in
the current session and the current scope.
Regards
Sivakumar
"Jo Inferis" wrote:

> I have an ASP.NET application with a SQL Server 2000 backend, where two
> pages fire off two different stored procedures. Each stored procedure
> creates a new record in a particular table then uses Scope_Identity() to g
et
> the id of the newly created record for adding it to a link table. The
> problem I'm seeing appears to be Scope_Identity() behaving as thought it
> were @.@.IDENTITY, i.e. on the occasion when both procedures are fired at on
ce
> (different machines and browsers, not that it should matter), one procedur
e
> appears to get the id of the record created by the other and essentially
> steal its record.
> Has anyone come across anything like this before?
> thanks in advance,
> --
> jo inferis
>
>|||Subramaniam Sivakumar wrote:
> Use IDENT_CURRENT('table_name') to get the Identity value.
That's not going to help, both identities are created in the same table.
Obviously I didn't make that clear enough.
jo inferis|||Mike Epprecht (SQL MVP) wrote:
> Do you have code to reproduce this issue?
It's a little difficult to extract the code to reproduce it, and this is
only a vague possibility anyway. I was just wondering if there might have
been something i'd missed in the usage of Scope_Identity().

> I only way I could think this happens is if both SP's are executed on
> the same connection (which is unlikely).
I did think about that, but even then, the scope in each case should be
different, shouldn't it?
jo inferis|||Is scope_identity() is returning the same identity of the other stored proc
perhaps you're application is using connection pooling. I'm guessing that
would explain how 2 different pages would end up being in the same "scope".|||I don't see how this can happen but maybe this will help:
Wrap all inserts in your stored procedure in a transaction.
We haven't seen any code so you may be doing this anyway.
"Jo Inferis" <jo@.inferis.NOSPAM.gotadsl.co.uk> wrote in message
news:%23LYkTseNFHA.1176@.TK2MSFTNGP12.phx.gbl...
> Mike Epprecht (SQL MVP) wrote:
> It's a little difficult to extract the code to reproduce it, and this is
> only a vague possibility anyway. I was just wondering if there might have
> been something i'd missed in the usage of Scope_Identity().
>
> I did think about that, but even then, the scope in each case should be
> different, shouldn't it?
> --
> jo inferis
>

Monday, February 20, 2012

Positioning of Stored Procedures

Hi all,

I have been facing this dilemma since when I started coding in asp.net 2.0. I can have Data Access Layer wherein I can write stored procedures to access the data from database. I can create data access object, data table and all other stuff. Also I can create stored procedure in SQL 2000 server, and then access them from the Data Access layer.

Which of the two method is preferable, and why. i have been searching net for answers to this question since long, but could not find anything.


All answers can contribute may be little but invaluable knowledge.

Thanks.

If security is critical, it's best to use stored procedures always because it lowers the attackable area of your database. I think this is what you are asking.

|||

I wanted to know, which is better:

1) Creating stored procedures in SQL Server 2000 and calling them in the Data access Layer, or may be in the code behind straight away.

2) Creating Table Adapters in Data Access Layer, and creating Table Adapter queries and accessing database or may be stored procedures within the Data Access Layer.

I have been informed that if you create the Table Adapter queries, they are equally secure as stored procedures; though i am not pretty confident about it.

Thanks again.

|||

Tell the truth, the issue is depending on your situation.

If you can connect database and your database permittion contol well, you need to do that on db.

if not, don't do that.

|||

Read this an argument against using SP. This will clarify your question as well

http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html

Hope that helps

|||

hello.

well, to be honest, sps aren't really something i'd advocate for crud behavior. in my opinion, using parametrized sql is the way to go. the performance/security bla bla that's has been used for several years is a myth and there are some posts out there that just show it. for instance, there's an old discussion between frans bouma and rob howard that started with a post from rob and a very well answer by frans. i'm putting only frans' post here since it is linked to rob's post.

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

having said that, i'm not saying that there really isn't a place for sps; just saying that kmost of the time the argument for using them are pure myths!

|||

Hi,

I feel creating stored procedures in SQL Server 2000 and calling them in the Data access Layer is better choice. The book Titled :

"Database programming using C#, VB 2005 and SQL Server 2005", Chapter 10:Developing Components for three-tier applications explains this concept.

Let us say we have developed an three-tier application using SQL server 2000. In future, the same application should able to access/insert to Oracle database. In this situation, writing stored procedures at the server level is better.

I will find out further info on this matter.

|||

With the technologies ASP.NET 2 provide, you r always free to choose the way you like (depending upon your handy side). With the nearly the same amount of effort or even less you can still handle the shift to Oracle database.

But that said, your approach of choosing store procedure suppose to be a little faster in most cases.

|||

hello.

ask4jm:

But that said, your approach of choosing store procedure suppose to be a little faster in most cases

again, this is a known myth. read frans' post to see what i'm speaking about.

|||

You r absolutely rite Luis. Unless the database developers wants to give the data through specific routines hiding rest of the infra, store procedures can be completely avoided.

|||

db2Command cmd= db2Commant();

cmd.Connection=con;
param = new DB2Parameter("@.ClientId", DB2Type.Decimal, 8);
((DbCommand)base.dbSelectCommand[0]).Parameters.Add(param);

//Insert Command and parameters
string sqlInserCommand = "ProcCon";

base.dbInsertCommand = new DbCommand[1];
base.dbInsertCommand[0] = new DB2Command(sqlInserCommand);

param = new DB2Parameter("@.Name", DB2Type.VarChar, 100, "ClientName");
((DbCommand)base.dbInsertCommand[0]).Parameters.Add(param);

param = new DB2Parameter("@.Cid", DB2Type.Int);
((DbCommand)base.dbInsertCommand[0]).Parameters.Add(param);