Microsoft SQL Server
 
Forums: » Register « |  User CP |  Games |  Calendar |  Members |  FAQs |  Sitemap |  Support | 
 
 
User Name:
Password:
Remember me
Iron Speed
Go Back   ASP Free ForumsDatabaseMicrosoft SQL Server

Reply
Add This Thread To:
  Del.icio.us   Digg   Google   Spurl   Blink   Furl   Simpy   Y! MyWeb 
Thread Tools Search this Thread Rate Thread Display Modes
 
Unread ASP Free Forums Sponsor:
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  
Old April 23rd, 2008, 03:04 PM
ArtJunky ArtJunky is offline
Contributing User
ASP Free Newbie (0 - 499 posts)
 
Join Date: Mar 2006
Posts: 87 ArtJunky User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 15 h 39 m 9 sec
Reputation Power: 3
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:
Originally Posted by Wolffy
In this case, you don't need a transaction since you are only making a single modification to the database. You would use a Transaction if you need to do multiple updates/inserts to the database, and want to rollback all changes should any of the updates/inserts fail.
I'm planning on inserting multiple form elements like addresss, name, ... but I don't think this is what you are talking about.
Quote:

Also, you @ins_error makes no sense here since it should be the error code from the INSERT table. By having it in the ELSE clause, you're getting the error code from the SELECT statement.
I don't think I understand this bit that you commented on. The way I understood it was the IF was checking if that user was taken if not, it adds it, if EXISTS, then it throws an error. ..."@ins_error

Quote:

And yes, it BEGIN TRANSACTION, ROLLBACK TRANSACTION and COMMIT TRANSACTION. You didn't specify where the COMMIT was coded, nor what the error was.

Reply With Quote
  #17  
Old April 23rd, 2008, 03:08 PM
ArtJunky ArtJunky is offline
Contributing User
ASP Free Newbie (0 - 499 posts)
 
Join Date: Mar 2006
Posts: 87 ArtJunky User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 15 h 39 m 9 sec
Reputation Power: 3
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.

Reply With Quote
  #18  
Old April 23rd, 2008, 03:35 PM
Wolffy's Avatar
Wolffy Wolffy is offline
Slaprentice of Wolves
Click here for more information.
 
Join Date: Aug 2007
Location: Mossville, IL
Posts: 1,015 Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level) 
Time spent in forums: 1 Week 4 Days 2 h 3 m 50 sec
Reputation Power: 329
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.

Reply With Quote
  #19  
Old April 23rd, 2008, 03:56 PM
ArtJunky ArtJunky is offline
Contributing User
ASP Free Newbie (0 - 499 posts)
 
Join Date: Mar 2006
Posts: 87 ArtJunky User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 15 h 39 m 9 sec
Reputation Power: 3
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:
Originally Posted by Wolffy
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.

Reply With Quote
  #20  
Old April 24th, 2008, 08:16 AM
Wolffy's Avatar
Wolffy Wolffy is offline
Slaprentice of Wolves
Click here for more information.
 
Join Date: Aug 2007
Location: Mossville, IL
Posts: 1,015 Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level) 
Time spent in forums: 1 Week 4 Days 2 h 3 m 50 sec
Reputation Power: 329
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.

Reply With Quote
  #21  
Old April 24th, 2008, 10:35 AM
Memnoch's Avatar
Memnoch Memnoch is offline
Unholy Moderator
ASP Free God 14th Plane (11500 - 11999 posts)
 
Join Date: Oct 2003
Location: In hell, where did you think?
Posts: 11,672 Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level)Memnoch User rank is Major (30000 - 40000 Reputation Level) 
Time spent in forums: 3 Weeks 4 Days 6 h 1 m 55 sec
Reputation Power: 356
Quote:
Originally Posted by ArtJunky
Thanks, that makes sense but won't most most hackers know that this is what I am doing?

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.

Reply With Quote
  #22  
Old April 25th, 2008, 09:21 AM
ArtJunky ArtJunky is offline
Contributing User
ASP Free Newbie (0 - 499 posts)
 
Join Date: Mar 2006
Posts: 87 ArtJunky User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 15 h 39 m 9 sec
Reputation Power: 3
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).

Reply With Quote
  #23  
Old May 5th, 2008, 01:23 PM
ArtJunky ArtJunky is offline
Contributing User
ASP Free Newbie (0 - 499 posts)
 
Join Date: Mar 2006
Posts: 87 ArtJunky User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 15 h 39 m 9 sec
Reputation Power: 3
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

Reply With Quote
  #24  
Old May 5th, 2008, 01:37 PM
Wolffy's Avatar
Wolffy Wolffy is offline
Slaprentice of Wolves
Click here for more information.
 
Join Date: Aug 2007
Location: Mossville, IL
Posts: 1,015 Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level) 
Time spent in forums: 1 Week 4 Days 2 h 3 m 50 sec
Reputation Power: 329
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.

Reply With Quote
  #25  
Old May 5th, 2008, 02:11 PM
ArtJunky ArtJunky is offline
Contributing User
ASP Free Newbie (0 - 499 posts)
 
Join Date: Mar 2006
Posts: 87 ArtJunky User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 15 h 39 m 9 sec
Reputation Power: 3
Quote:
Originally Posted by Wolffy
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.


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

Reply With Quote
  #26  
Old May 5th, 2008, 02:20 PM
ArtJunky ArtJunky is offline
Contributing User
ASP Free Newbie (0 - 499 posts)
 
Join Date: Mar 2006
Posts: 87 ArtJunky User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 15 h 39 m 9 sec
Reputation Power: 3
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

Reply With Quote
  #27  
Old May 5th, 2008, 02:33 PM
Wolffy's Avatar
Wolffy Wolffy is offline
Slaprentice of Wolves
Click here for more information.
 
Join Date: Aug 2007
Location: Mossville, IL
Posts: 1,015 Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level)Wolffy User rank is Major (30000 - 40000 Reputation Level) 
Time spent in forums: 1 Week 4 Days 2 h 3 m 50 sec
Reputation Power: 329
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:
Original - SQL Code
  1. CREATE PROCEDURE Insertuser
  2. @FName varchar (50),
  3. @LName varchar (50),
  4. @PassWord  varchar (20),
  5. @Email varchar (50),
  6. @ShipName varchar (100),
  7. AS
  8.  
  9. DECLARE @err1 INT
  10.  
  11.     -- If the email is already then return some unique
  12.     -- error that we can check or.
  13.     IF EXISTS (
  14.         SELECT   EMail
  15.        FROM   Customer
  16.        WHERE   EMail = @Email)
  17.     BEGIN
  18.       RETURN -10101
  19.     END
  20.    
  21.     BEGIN TRANSACTION
  22.         -- Email Appears to be unique so
  23.         -- Insert the users information
  24.         INSERT INTO atblCustomer (FName, LName, Email, Password)
  25.              VALUES (@FName, @LName, @Email, @Password)
  26.         SET @err1 = @@ERROR
  27.        
  28.         -- If the insert fails...
  29.         IF @err1 <> 0
  30.         BEGIN
  31.             -- ..specfiicaly check if the violated uniqueness
  32.             IF @err1 = 547
  33.              PRINT 'A constraint error has occurred.'
  34.             ELSE
  35.              PRINT 'An unspecified error has occurred.'