Newbie: Calculations using Currency
Author Message
Newbie: Calculations using Currency

Is there a bug in the Currency setting in VB?

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,

Magic

Wed, 08 Sep 2004 01:11:58 GMT
Newbie: Calculations using Currency

Quote:
>  Dim wsCheck, wsPymt, wsExp, wsDiff As Double

This doesn't do what you think.  The first three variables take the default
datatype, which is variant.  Unless you want variant, dim each variable
separately.

Quote:
>     wsCheck = Text1(10)

Since wsCheck is variant, this assignment coerces the variant to a string
and assigns a string to it.

Quote:
>        wsExp = rs5.Fields("Expected_Amt")

This assignment coerces the variant to a numeric datatype to hold the value.

Quote:
>        If wsCheck >= wsExp Then

wsCheck is a variant containing a string and wsExp is a variant containing a
numeric.  I don't know the rules for comparing different datatypes, so I
don't know when this would be true or false.

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.

Good luck with your development effort.

Wed, 08 Sep 2004 01:52:30 GMT
Newbie: Calculations using Currency
HI George,
Thanks for your most interesting post.  Being a Newbie I do appreciate your
suggestions.  It gives me alot to think of in terms of organizing my code.

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

Quote:

> >  Dim wsCheck, wsPymt, wsExp, wsDiff As Double

> This doesn't do what you think.  The first three variables take the
default
> datatype, which is variant.  Unless you want variant, dim each variable
> separately.

> >     wsCheck = Text1(10)

> Since wsCheck is variant, this assignment coerces the variant to a string
> and assigns a string to it.

> >        wsExp = rs5.Fields("Expected_Amt")

> This assignment coerces the variant to a numeric datatype to hold the
value.

> >        If wsCheck >= wsExp Then

> wsCheck is a variant containing a string and wsExp is a variant containing
a
> numeric.  I don't know the rules for comparing different datatypes, so I
> don't know when this would be true or false.

> 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.

> Good luck with your development effort.

Thu, 09 Sep 2004 22:39:49 GMT
Newbie: Calculations using Currency

Quote:
> HI George,
> Thanks for your most interesting post.  Being a Newbie I do appreciate
your
> suggestions.  It gives me alot to think of in terms of organizing my code.

> 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?

I'm delighted if you have found some value in my comments.  In my opinion,
the issues that you are asking questions about are the ones that distinguish
a programmer with a professional level of expertise and an amateur.

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.

Good luck with your development effort.

Sat, 11 Sep 2004 12:34:49 GMT

 Page 1 of 1 [ 4 post ]

Relevant Pages