I read the Text portion of your question and it really sounds like you are trying to do the database's work for it, which is always inefficient, if possible DON'T. Especially when it comes down to rolling back transactions.

in the case where you need to do a bunch of different queries and rollback if something goes wrong, create a stored procedure that calls all these queries.

Use the SQL Database for what it was meant to be used for.

SQL Server is good at querying data and performing operations on data, and it has ways of catching errors and rolling back the entire thing. Go do that, it will be much easier in the long run.

I'm trying to find out what is the best way to create a class so I can use it to connect to the SQL Server and be able to rollback everything if a single error exists.

This sounds very much like what a transaction is used for. Looking at the code, you have that part covered... somewhat.

The abstractions are wrong. First thing that hits me is this:

Inherits System.Web.UI.UserControl

Why would data access logic ever need to be entangled with UI controls? What you need is to encapsulate a transaction - a "normal" class can do that, and its implementation can stay off the UI layer's code.

Then there's this:

Private bdConection As Data.SqlClient.sqlConnection
Private bdTransaction As Data.SqlClient.sqlTransaction
Public bdCommand As Data.SqlClient.SqlCommand

The first two would be fine, if the third didn't stick out like a sore thumb: fields should not be Public; exposed fields break encapsulation and open up your code to all kinds of unnecessary issues and edge cases (e.g. what happens when the bdCommand reference is reassigned by external code, in the middle of a transaction?).

One problem, is that SqlConnection, SqlTransaction and SqlCommand types all implement the IDisposable interface, and as such should be as short-lived as possible, and properly disposed: setting a disposable reference to NOTHING does not dispose it. Your class owns these instances, and should be responsible for their disposal... which should happen in the Dispose() method, which doesn't seem to be overridden.

Now, if you went and properly disposed the disposables there, you would run into a bunch of new problems, such as ObjectDisposedException getting thrown all over the place. The reason for that is that you're reusing objects that shouldn't be.

The correct abstraction for encapsulating a transaction, is a unit of work - a simple one could look like this:

Public Interface IUnitOfWork
    Sub Commit()
    Sub Execute(command As SqlCommand)
    Function Select(command As SqlCommand) As DataTable
End Interface

You don't need a Rollback() method there, because if you dispose the unit of work before you commit, you're effectively cancelling all pending changes. I added an Execute method here taking an SqlCommand object, because I don't want to get into repositories, so the idea is to expose a method that can run a command within a transaction's scope.

Public Class UnitOfWork Implements IUnitOfWork, IDisposable

    Private ReadOnly connection As SqlConnection
    Private ReadOnly transaction As SqlTransaction

    Public Sub New(connection As SqlConnection)
        '' assume connection owner already opened the connection (document that!)
        Me.connection = connection
        Me.transaction = Me.connection.BeginTransaction(IsolationLevel.ReadCommitted)
    End Sub

    Public Sub Execute(command As SqlCommand)
        '' assume command owner already set up parameters and cmd text (document that!)
        command.Transaction = Me.Transaction
        command.Connection = Me.connection
        command.ExecuteNonQuery()
    End Sub

    Public Function Select(command As SqlCommand) As DataTable
        '' assume command owner already set up parameters and cmd text (document that!)
        command.Transaction = Me.Transaction
        command.Connection = Me.connection
        Using reader = command.ExecuteReader()
            Dim result As DataTable = New DataTable
            result.Load(reader)
            Return result
        End Using
    End Function

    Public Sub Commit()
        Me.Transaction.Commit()
    End Sub

    Public Sub Dispose()
        Me.Transaction.Dispose()
    End Sub

End Class

You would use it something like this:

Private Sub DoSomething(connection As SqlConnection)
    Using uow = New UnitOfWork(connection)
        Try
            uow.Execute(GetCommandForFoo())
            uow.Execute(GetCommandForBar())
            uow.Commit()
        Catch exception As SqlException
            '' message? log? whatever...
        End Try
    End Using
End Sub

If you need a new transaction, you need a new UnitOfWork instance. But if you're doing things right, you shouldn't need to Commit more than once per request anyway.

Other Points

• Naming is not following the typical VB.NET conventions. Use PascalCase for object members (methods, etc.), and avoid cryptic prefixes (what's that meaningless s I'm seeing everywhere?)
• I would not have sBDNonQuery return a Boolean. If that command failed, something is wrong and you want to rollback anyway: just let the exception bubble up instead.
• Try : bdTransaction.Commit() : Catch : End Try is very, very, very bad: if the transaction can't be committed, you need to know - and at least log something about it. By swallowing any exception that might occur there, you're setting yourself up for some nightmareish debugging later.
• 4 try/catch blocks in a single method is a code smell all by itself.
• Where's the last r in erro and sErro?
• rs is what we used to name our ADODB.Recordset object instances in VB6/VBA. This is .NET, and it's a DataTable. Name accordingly.
• If you're targeting .NET > 2.0, I would strongly recommend looking into newer data access technologies, which abstract away all the SQL-handling and SqlCommand boilerplate. Start with LINQ-to-SQL, then see what Entity Framework can do for you.