Can you store datasets in the viewstate? Should we?

[darrel]

When I write scripts for deleting records in databases, I tend to do it in
this fashion:

- delete link passes ID to a delete.aspx page
- delete.aspx page queries db using that ID to retrieve the file
information
- page displays file information with a 'are you sure you want to delete'
confirmation button.
- upon clicking said button, I delete the record.

Simple enough.

At times, though, I need to delete multiple records related to one record as
well as actual files in the filesystem related to the record.

In that case, I tend to use this method:

- delete link passes ID to a delete.aspx page
- delete.aspx page queries db using that ID to retrieve the file
information
- page displays file information with a 'are you sure you want to delete'
confirmation button.
- upon clicking said button, I requery the db to get the data again
- I loop through the dataset returned to delete the related content first,
then delete the parent record

In that method, I query the DB twice for essentially the same data.

Would it make more sense to query once, then store the data in the viewstate
(if I can). Or is it not a big deal to just do a double query.

As these are small datasets, it's probably a moot issue at this point, but
for future reference, I'd like to understand the best practices for this
type of situation.

-Darrel

[Mark Rae]

"darrel" <no*****@nowhere.comwrote in message
news:ut**************@TK2MSFTNGP02.phx.gbl...

When I write scripts for deleting records in databases, I tend to do it in
this fashion:

<snip>

Simple enough.

Yes, but you're making me wonder if you're using ASP Classic or ASP.NET. For
one thing, when you talk about writing "scripts", do you mean VBScript or
JavaScript? You surely don't refer to VB.NET or C# as "scripts"...???

OK, so you talk about ViewState, so you must be using ASP.NET, but why on
earth do you need a separate page to carry out your database writes? This is
very much the awful ASP Classic kludge which the ASP.NET Postback
functionality was designed to replace...

- delete.aspx page queries db using that ID to retrieve the file
information

Again, in ASP.NET, you would ask that question *before* the postback

<asp:Button ID="cmdDelete" Text="Delete" OnClick="cmdDelete_Click()"
OnClientClick="return confirm('Are you sure you want to delete this
record?');" />

I'd like to understand the best practices for this type of situation.

Use Postback...

[darrel]

Yes, but you're making me wonder if you're using ASP Classic or ASP.NET.

For one thing, when you talk about writing "scripts", do you mean VBScript
or JavaScript? You surely don't refer to VB.NET or C# as "scripts"...???

I do when I don't fully think about it before writing. ;o)

No, this is asp.net, I should have said functions. Not scripts.

Again, in ASP.NET, you would ask that question *before* the postback

Correct:

page loads
button click 'confirms'
postback deletes record

>I'd like to understand the best practices for this type of situation.

Use Postback...

I am. But that wasn't really the question. The question is can I and/or
should I store a dataset in the viewstate to carry it over from page load to
the postback? Or should I just requery the DB upon postback?

-Darrel

[Mark Rae]

"darrel" <no*****@nowhere.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

I am. But that wasn't really the question. The question is can I and/or
should I store a dataset in the viewstate to carry it over from page load
to the postback? Or should I just requery the DB upon postback?

Get rid of the additional delete page, and you won't have to worry about
this...

[darrel]

Get rid of the additional delete page, and you won't have to worry about

this...

I prefer a separate delete page. I tend to use a 'master' delete page to
handle all record deletions in the app.

Is this bad? If so, why?

Regardless, even if it's the same page, I still have the issue I am asking
about. When I have to delete multiple records that requires a database query
to determine said relations, can I store that in viewstate to pass it back
to the page on postback? Should I?

-Darrel

[Mark Rae]

"darrel" <no*****@nowhere.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>Get rid of the additional delete page, and you won't have to worry about
this...

I prefer a separate delete page. I tend to use a 'master' delete page to
handle all record deletions in the app.

Is this bad? If so, why?

I wouldn't call it "bad" per se - just completely unnecessary, IMO...

Regardless, even if it's the same page, I still have the issue I am asking
about. When I have to delete multiple records that requires a database
query to determine said relations, can I store that in viewstate to pass
it back to the page on postback? Should I?

Obviously you *can* do this - you can do anything you like... :-)

As to whether you *should* or not, it's difficult for me to say because,
IMO, it's totally unnecessary anyway...

[darrel]

As to whether you *should* or not, it's difficult for me to say because,

IMO, it's totally unnecessary anyway...

What part of this do you find unecessary?

I need to to data from the database to construct the confirmation to delete
message. Ie, 'do you want do delete file [name of file from database]'

Then I need to get data from the database to find all the related records
that need deleting.

What other way are you proposing?

No matter how I set this up, I ultimately need/want three 'nodes' on the
flow chart:

1) see record with delete option. If clicked on...
2) see record asking to confirm the delete. If clicked on...
3) delete the record and present confirmation message.

-Darrel

[Mark Rae]

"darrel" <no*****@nowhere.comwrote in message
news:u$*************@TK2MSFTNGP06.phx.gbl...

What part of this do you find unecessary?

The "middle" stage.

I need to to data from the database to construct the confirmation to
delete message. Ie, 'do you want do delete file [name of file from
database]'

Obviously. You'd do this as part of your initial databinding process...

Then I need to get data from the database to find all the related records
that need deleting.

??? Of course you don't!

What other way are you proposing?

CREATE PROC DeleteRecords
@intPrimaryKey int

DELETE FROM <RelatedTable1>
WHERE <ForeignKey= @pintPrimaryKey

DELETE FROM <RelatedTable2>
WHERE <ForeignKey= @pintPrimaryKey

DELETE FROM <MainTable>
WHERE <PrimaryKey= @intPrimaryKey

Wrap the individual deletes in a transaction for additional robustness.

No matter how I set this up, I ultimately need/want three 'nodes' on the
flow chart:

Ah, but that's different! If you *want* to go through the superfluous middle
stage, that's perfectly fine - it's your app! All I'm saying is that it's
completely unnecessary...

1) see record with delete option. If clicked on...
2) see record asking to confirm the delete. If clicked on...

Surely they're the same thing, no...?

[darrel]

>What part of this do you find unecessary?

>
The "middle" stage.

Are you suggesting a confirmation isn't necessary? I guess I'd have to
disagree with that.

Or are you suggesting that the specific way I'm doing the confirmation is
unecessary. I'm not quite clear on what the alternative you are prposing is.

>I need to to data from the database to construct the confirmation to
delete message. Ie, 'do you want do delete file [name of file from
database]'

Obviously. You'd do this as part of your initial databinding process...

Right.

>Then I need to get data from the database to find all the related records
that need deleting.

??? Of course you don't!

Oh!? That's my question. ;0)

Your example of the stored procedure works, but that doesn't help me delete
the physical files on the server. I still need to grab that data from the
database, so I can then delete the files from the filesystem.

Ah, but that's different! If you *want* to go through the superfluous
middle stage, that's perfectly fine - it's your app! All I'm saying is
that it's completely unnecessary...

>1) see record with delete option. If clicked on...
2) see record asking to confirm the delete. If clicked on...

Surely they're the same thing, no...?

Yea, I think we're saying the exact same thing there...you're just not
actually writing out the 3rd node (delete and show confirmed deletion)

I think your suggestion makes perfect sense if I didn't have to find out the
filenames I need to delete from the filesystem. That seems to be the catch.

-Darrel

[Mark Rae]

"darrel" <no*****@nowhere.comwrote in message
news:OG**************@TK2MSFTNGP06.phx.gbl...

Are you suggesting a confirmation isn't necessary? I guess I'd have to
disagree with that.

No - I'm merely suggesting that only *one* confirmation is necessary - with
OnClientClick

Or are you suggesting that the specific way I'm doing the confirmation is
unecessary. I'm not quite clear on what the alternative you are prposing
is.

I'm saying that you only need to ask the user *once* if they want to delete
the record, and all its associated records...

Your example of the stored procedure works, but that doesn't help me
delete the physical files on the server. I still need to grab that data
from the database, so I can then delete the files from the filesystem.

??? Why do you need to "grab" them??? Simply tell SQL Server to delete them
as part of your stored procedure...

I think your suggestion makes perfect sense if I didn't have to find out
the filenames I need to delete from the filesystem. That seems to be the
catch.

??? But you already know the filenames that need to be deleted!!! They're
stored in your database.

Or are you saying that your SQL Server box can't actually see the files to
be deleted - it merely stores their filespecs...?

[darrel]

I'm saying that you only need to ask the user *once* if they want to

delete the record, and all its associated records...

Right. I am only asking once.

??? But you already know the filenames that need to be deleted!!! They're
stored in your database.

No, they're stored in the filesystem.

Or are you saying that your SQL Server box can't actually see the files to
be deleted - it merely stores their filespecs...?

Right.

-Darrel

[Mark Rae]

"darrel" <no*****@nowhere.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>I'm saying that you only need to ask the user *once* if they want to
delete the record, and all its associated records...

Right. I am only asking once.

Er, no - once when the user first clicks the Delete button, and then once
more when they've been redirected to your delete page...

>??? But you already know the filenames that need to be deleted!!! They're
stored in your database.

No, they're stored in the filesystem.

??? OK - I'm obviously missing the point here... Are the filespecs of the
files to be deleted stored in your database or not? If not, then what's the
point of your second database query...???

[darrel]

Er, no - once when the user first clicks the Delete button, and then once

more when they've been redirected to your delete page...

The first click doesn't prompt any sort of confirmation dialog on that page.
That's what the deletePage.aspx is for.

I don't want the delete button to immediately delete the file without an
'are you sure' dialog of some sort.

??? OK - I'm obviously missing the point here...

Yea. Sorry. We're going on here, aren't we. ;o)

Are the filespecs of the files to be deleted stored in your database or
not? If not, then what's the point of your second database query...???

The file name is stored in the database. That's the reason for the second
query. To get the filename so I cand delete the file from the filesystem.
The files themselves are NOT in the database.

Obviously, this is one argument for actually putting them in the database.
;o)

-Darrel

[Mark Rae]

"darrel" <no*****@nowhere.comwrote in message
news:On**************@TK2MSFTNGP06.phx.gbl...

>Er, no - once when the user first clicks the Delete button, and then once
more when they've been redirected to your delete page...

The first click doesn't prompt any sort of confirmation dialog on that
page. That's what the deletePage.aspx is for.

I don't want the delete button to immediately delete the file without an
'are you sure' dialog of some sort.

>??? OK - I'm obviously missing the point here...

Yea. Sorry. We're going on here, aren't we. ;o)

>Are the filespecs of the files to be deleted stored in your database or
not? If not, then what's the point of your second database query...???

The file name is stored in the database. That's the reason for the second
query. To get the filename so I cand delete the file from the filesystem.
The files themselves are NOT in the database.

Obviously, this is one argument for actually putting them in the database.

Fair enough - just a difference of opinion, I guess...

If I were doing this, my flow would be the following:

1) User clicks button

2) Button's OnClientClick is something like "return confirm('Are you sure
you want to delete this record and all its associated files?');"

3) If user responds "Yes", page posts back and calls the button's Click()
method server-side

4) Button's click method calls a SQL Server stored procedure which:

a) fetches a recordset of the associated files
b) walks through the recordset deleting each file
c) deletes the records from the recordset
d) deletes the primary record