The following works fine if the wsCheck is >= to
the first wsExp.
Example: wsCheck = $30.00
         wsExp(1)= 10
         wsExp(2)= 10
         wsExp(3)= 30
The $30.00 > 10.

But if the wsCheck is < the first wsExp,
Example: wsCheck = $5.00
         wsExp(1)= 10
         wsExp(2)= 10
         wsExp(3)= 30
it takes the $5.00 as > 10.

I've tried making the variables "Currency,
but still does not work right.

My Code
-------
 Dim wsCheck, wsPymt, wsExp, wsDiff As Double
    wsCheck = Text1(10)
    Do Until rs5.EOF = True
       wsExp = rs5.Fields("Expected_Amt")

       If wsCheck >= wsExp Then
          wsPymt = wsExp
          wsCheck = wsCheck - wsExp
         Else
           If wsCheck > 0 Then
              wsPymt = wsCheck
              wsDiff = wsCheck - wsExp
              wsCheck = wsCheck - wsExp
             Else
              wsPymt = 0
              wsDiff = wsExp * -1
           End If
       End If
       rs5.Edit
       rs5.Fields("Payment") = wsPymt
       rs5.Fields("Difference") = wsDiff
       rs5.Update
       rs5.MoveNext
    Loop
    Data5.Refresh

  Any help given will be appreciated,

Your code is going to be full of hard to understand problems like this
unless you adopt some coding conventions.  Here are my own rules:

1. Always explicitly declare variables with the correct datatype for the
data.
2. Use hungarian notation to make it obvious what datatype a variable is.
3. Never allow VB to coerce a value, always convert datatypes explicitly.

This would make your code look something like this (using my own hungarian):

Dim lc_Check As Currency
Dim lc_ExpectedAmount As Currency

lc_Check = CCur(text1(10))

Do Until rs5.EOF
    lc_ExpectedAmount = CCur(rs5.Fields("Expected_Amt"))

    If lc_Check >= lc_ExpectedAmount Then

I can see lots of other problems you are going to encounter.  What if
text1(10) is not numeric?  What datatype is text1 anyway?  What if
Expected_Amt is null?  For production applications, the goal is to make them
"robust", or cabable of handling their own errors and running with few
exceptions.  You need to evaluate your design with the goal of making it
more robust.

There are some other issues with your code.  In my opinion, "rs5" is a
horrible name for a variable, and it makes me think that you probably have
four other recordsets similiarly named.  Try to break your code into
subroutines and pass in the variables they need.  Having five recordsets in
a module and referring to them all over the place is going to make your
program a nightmare to work on.

One last thing: if these five recordsets all have active connections, I hope
you don't expect to open many more connections to the same database.

Is there a limit to the amount of tables you can have within a database?
Is there a limit on the number of tables you can have open and or active at
one tim?  How about the number of databases open at one time?

                                                   Magic

I have a few recommendations concerning database access for business apps:

1. Use nothing but ADO for your data access.  Sometime in the near future, I
will also recommend that you don't write any ADO code that you don't also
test on .net, but I have yet to encounter it in the production environment.

2. Always use DSN-less connnections.  Search MSDN for more info.

3. Get your DSN connection strings from the registry or a database.  Doing
this last will be tricky, because you will have to have a database
connection in order to get your connection strings, if you see what I mean.
Improve your production DBIO code continuously and focus on robustness.

4. Get the MSPress book  Programming Distributed Applications with COM+ and
Microsoft Visual Basic6.0, read it and understand the issues that it
presents.  Specifically, learn about the performance issues regarding
database connections.  Hint: Most SQL Server installations you encounter
will have 5 connection licenses.  If you open persistent database
connections, and you want to have six users, you are screwed.  If you open
six connections in the same app, you are screwed six times over.  Also, my
advice is *do not use Access for production applications*.

5. Learn how to package all of your DBIO up in classes, or even better, in
activex dlls.  This will encapsulate it and hide it from the presentation
layer.  This will save you a ton of time in future development.

6. Make sure you are using a change control tool for all of your
development.  In a MS environment, the best tool to use is VSS.  Put
everything you do, no matter how small, in it.

As for your questions about the limits of database characteristics, I am
sure you can find the answers in the doco, but I myself have no idea.  In my
opinion, if you are developing a business app and you are getting anywhere
close to the limits of anything in VB or the data layer, then you have made
a design mistake somewhere.