|
|
|||||||||
|
|||||||||
|
|||||||||
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|
|
Ajax Application Generator Generate database and reporting .NET Web apps in minutes. Quickly create visually stunning, feature-rich apps that are easy to customize and ready to deploy. Download Now!
|
|
#16
|
|||||
|
|||||
|
Of course, I'm back. So, here's another one I came up with that runs but I'm not sure if it's doing what I really want.
Code:
CREATE Procedure Insertuser
@varUser varchar (50),
@varPass varchar (20)
As
BEGIN TRANSACTION
IF NOT EXISTS (
SELECT EMail
FROM atblCust
WHERE EMail = @varUser
)
BEGIN
INSERT INTO atblCust (EMail, Password)
VALUES (@varUser, @varPass)
END
IF @@ERROR <> 0
BEGIN
--ROLLBACK THE TRANSACTION
ROLLBACK TRANSACTION
--RAISE AN ERROR AND RETURN
RAISERROR ('Could not insert user', 16, 1)
RETURN
END
COMMIT TRANSACTION
GO
Quote:
Quote:
Quote:
|
|
#17
|
|||
|
|||
|
Wolffy,
I didn't realize that you were posting just as I was doing my little victory dance...ah, arrogance. I spoke too soon...again. |
|
#18
|
||||
|
||||
|
A transaction is for when you want to execute multiple SQL Statements that modify the database, and have the ability to commit the changes ONLY if ALL the statements execute correctly. It does not mean multiple columns changed in a single INSERT statement (tho it would if you had a LOOP structure and was executing the same INSERT statement multiple times). In you proc, you execute only a single INSERT statement, and so it either works or it doesn't. If it doesn't, the table hasn't change and there is nothing to rollback anyway.
The EXISTS function returns either TRUE or FALSE; TRUE if the number of rows returned by the SELECT query is > 0 and FALSE otherwise. Nothing in this statement alters the database, and there is very little that can throw an error. The RaiseError is OK here, but a little more expensive in terms of processor power. Not recommending that you change it.
__________________
Wolffy ------------------------ Teaching people to fish. |
|
#19
|
|||
|
|||
|
I was trying to keep this simple until I started understanding it.
I was planning on saving the user, billing and shipping information with one SP. Because it's two different tables should I use transaction? Is this right or is this still considered one transaction? I guess what I should ask is can I/should I select both tables and insert all the form variables into it? Or, should I use two insert statements and insert Billing using one insert, check it for errors and then insert Shipping, check for errors and commit? Quote:
|
|
#20
|
||||
|
||||
|
In this case, the use of a Transaction is correct. Begin the transaction, execute the two INSERT statements, and then commit. If either INSERT fails, then you [i[would[/i] want to rollback the changes.
|
|
#21
|
||||
|
||||
|
Quote:
Realistically, you can't prevent a hacker from attempting attacks on your site, but you can and should do everything you can to prevent disclosing too much information. Information that would help a hacker attack you. All you can do is create the app as securely as possible. |
|
#22
|
|||
|
|||
|
Thanks for the help. Let's see how far I get with this now that I have the basic format.
I wish there was a book that had real world examples using SP and Dreamweaver. I'm looking for someone to write a book that says: "This is how you do...(fill in the task). |
|
#23
|
|||
|
|||
|
I am back
I got the SP to add to the database using one of the methods
However, I don't think it was actually doing the transaction check on the email. Consequently, it would allow the user to add the user and then if they hit refresh, it would add it all again. This shouldn't happen if the check on the email was working. So then I updated the Stored Procedure and the transaction failed if I tried to add using the form but now I don't know what is causing it to fail. I don't have any messages to check and see where it is failing and what is causing it to fail where it did. See below: Code:
CREATE Procedure Insertuser
@FName varchar (50),
@LName varchar (50),
@PassWord varchar (20),
@Email varchar (50),
@ShipName varchar (100),
As
DECLARE @err1 INT
DECLARE @err2 INT
BEGIN TRANSACTION
BEGIN TRANSACTION
IF NOT EXISTS (
SELECT EMail
FROM Customer
WHERE EMail = @Email)
INSERT INTO atblCustomer (FName, LName, Email, Password)
VALUES (@FName, @LName, @Email, @Password)
SET @err1 = @@ERROR
IF @err1 <> 0
BEGIN
IF @err1 = 547
PRINT 'A constraint error has occurred.'
ELSE
PRINT 'An unspecified error has occurred.'
ROLLBACK TRANSACTION
RETURN @err1
END
ELSE
COMMIT TRANSACTION
BEGIN TRANSACTION
INSERT INTO atblShipAddress (ShipName)
VALUES (@ShipName)
SET @err2 = @@ERROR
IF @err2 <> 0
BEGIN
IF @err2 = 547
PRINT 'A constraint error has occurred.'
ELSE
PRINT 'An unspecified error has occurred.'
ROLLBACK TRANSACTION
RETURN @err2
END
ELSE
BEGIN
COMMIT TRANSACTION
RETURN 0
END
IF (@err1 <> 0) OR (@err2 <> 0)
ROLLBACK TRANSACTION
ELSE
COMMIT TRANSACTION
GO
|
|
#24
|
||||
|
||||
|
I think you need to do some reading about Transaction, because it's clear you don't understand the concept. In your snippit, you begin the transaction twice -- you either have a current transaction or you don't -- you can't nest them. Then, after you determine that the first INSERT works, you Commit the transaction, thus if the second INSERT fails, the first is already committed and you have a transaction complete. Start the Transaction at the top of body of the spoc, and commit it at the end. The way you have your transactions set up, you have only a single SQL statement in the transaction and thus nullify the benefits of the transaction.
Also, if either statement fails, you return from the sproc (correctly), so there is no need for the final IF statment since neither err1 nor err2 will non-zero at this point. |
|
#25
|
|||
|
|||
|
Quote:
I found this snippet out on the web and adapted it pretty much the same way it was but used my own variables. Consequently, it looked good to me because, like you said, I really don't understand Transaction. FYI, I'm a designer and the problem I keep running into is that even if I do read about this stuff, it never seems to mesh with what I want to accomplish and therefore, I'm not able see the big picture and apply what I just read about in the book to the project. What's stranger still is the fact that this is probably one of those things that are done on every site with a cart yet there's no book that demonstrates this in a way that a designer can use. At least I haven't found it. What I really need is some professional training where someone could step me through some of this. Wish I knew where to go. Unfortunately, when I'm on a deadline to get something done, of course there's no time to prepare for what I didn't know I didn't know. Man, this really just sucks! Thanks for being there to help. I do appreciate it; I will try to follow what you suggested. Thanks |
|
#26
|
|||
|
|||
|
How about this?
How about something like this...
Would this work for what I want to accomplish? Code:
DECLARE @intErrorCode INT
BEGIN TRAN
UPDATE Authors
SET Phone = '415 354-9866'
WHERE au_id = '724-80-9391'
SELECT @intErrorCode = @@ERROR
IF (@intErrorCode <> 0) GOTO PROBLEM
UPDATE Publishers
SET city = 'Calcutta', country = 'India'
WHERE pub_id = '9999'
SELECT @intErrorCode = @@ERROR
IF (@intErrorCode <> 0) GOTO PROBLEM
COMMIT TRAN
PROBLEM:
IF (@intErrorCode <> 0) BEGIN
PRINT 'Unexpected error occurred!'
ROLLBACK TRAN
END
|
|
#27
|
||||
|
||||
|
That appears to pretty much what you are looking for. Couple of comments of course. It uses UDPATE rather than INSERT, which matters not at all. I really don't like the use of GOTO, but what the heck, it works. I'd put a Return before the PROBLEM label and thus not need the IF statement there. However, I took your snippet from above and reworked it. Hope it helps: SQL Code:
|