Parameterized Procedures in SQL Server
WRT the procedure - take a second look at the fields and the table you're trying to populate in the INSERT statement; there's a problem there.

I'm trying to figure out why you have an acct_queue_bridge table. This normally is used to maintain a many-to-many relationship. I'm assuming that a queue belongs to one account, not many? Even if an account can have many queues, you'd only need the bridge if one queue ties to multiple accounts.

However, it's true that each account can have many DVDs on its queue, and each DVD could be on many queues. I would eliminate acct_queue_bridge, add account_id to the queue table, and use that as a bridge between account and dvds

I see a few other similar things that I'd question:


Can a customer have multiple accounts? (this is not unusual - allowing an account for each member of the family. However, only include it if the project seems likely to need it).
If the customer has multiple accounts, would there be a separate rental plan for each? I would think not: I would expect there to be a reference table of the different rental plans in use and/or available, and for each customer to sign up for one instance of those plans; in which case, it's possible to store the rental_plan_id in the customer table directly. You might need to track the customer's rental plan history; then you would probably have a separate table with the customer, the plan, and the date range when the plan was active. The current plan could be included there, or it could live in customer, and be copied into a cust_plan_hist table when it changed.
You currently have a queue_id in the dvds table. I would expect one DVD to be able to be in many queues (however, see my next point). I don't see why you'd link a DVD to a specific queue; perhaps I'm missing something here.
I believe that dvds and your inventory table will be closely related, if not one and the same. I'm assuming a row in dvds represents the idea of a movie/show on DVD, not a specific physical disk. in an actual Netflix business, dvd_inv (or whatever) would be where the actual physical disks are represented. You would need that there because each disk will have some sort of inventory number on it, and you'd track the status of each disk: available, shipped to , missing, whatever. You would probably want to track things like the condition of each disk (so if something leaves pristine and comes back scratched up, you can approach your customer about the change), and of course which specific disk is in the hands of which specific customer. However, as this is not necessarily intended to be a "real world" system, I'm not sure if you need to implement that level of detail - you might be able to get away with just having "bucket" fields to hold those numbers in the dvds table itself (3 available, 5 shipped to customers, 1 missing = 9 total).
Note that some instructors will actual object to you designing a more realistic system than they're asking for, because it becomes more difficult for them to assess and grade. Other instructors will applaud the initiative to go above and beyond the minimum requirements. However, once you start that way, if you run into problems later on, you may have to back out and re-implement parts of your solution to meet future parts of the assignment. I'd recommend sticking as close as possible to the actual requirements in school. In the real world, thinking a step or two ahead of your customer is quite valuable during the design phase, and can save your time and their money (something of a double-edged sword, at times, I suppose :-).