Access 2003 create text based on decimal numbers

I have a table (TblItems) with fields Lenght, Width and Height as
decimalfields. I also have the fields Desc, a text field.

In a form I have created this line of code after updating:
Desc = Lenght & " x " & Width & " x " & Height

If the values is 100, 100, 100 the result is 100 x 7920 x 100.

No matter what value I put into the width field It comes out with the
same 7920. Why??

This probably has some silly simple sollution........

You should discard the Desc field! It is not needed and will become
problematic. When you need the Desc in a form or report, you should create
the expression with a formula similar to the one you show in your post.

Re: problem with your code ---
Width is a reserved word used to express the width of a control on a form or
report. The default unit of measurement is a twip which is 1/1440 of an
inch. So if you are getting 7920 twips, the width of your textbox is 5.5
inches.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
resource@pcdatasheet.com




"Ulv" <lars@johs-nilsen.nowrote in message
news:1180357889.706476.95430@g4g2000hsf.googlegrou ps.com...

On May 28, 3:20 pm, "Steve" <s...@private.emailaddresswrote:Thank you so much !! Re. the desc field I need it in case it will be
changed later.....

Re: Desc field
It is still a mistake to have the Desc field in your table!! You undoubtedly
will regret it later.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
resource@pcdatasheet.com




"Ulv" <lars@johs-nilsen.nowrote in message
news:1180361032.874998.310440@w5g2000hsg.googlegro ups.com...

"Ulv" <lars@johs-nilsen.nowrote in message
<1180357889.706476.95430@g4g2000hsf.googlegroups.c om>:You might want to look at these two references with regards to your
naming convention

http://support.microsoft.com/kb/321266/EN-US/
http://support.microsoft.com/default...b;en-us;286335

as some of your names are reserved words.

For the moment, you might workaround your issues by using [brackets]

Me![Desc] = Me![Lenght] & " x " & Me![Width] & " x " & Me![Height]

But why store the value, when you can calculate/concatenate it each
time you need it?

Why you get 7920? Because you are using a reserved word as name of
something, and you don't qualify it in any way, Access picks the
width property of the current active object, which is most likely
the form. Width will then probably be the width of the form.

7920/567 -form width of 13,97 cm?

--
Roy-Vidar

"Steve" <sorry@private.emailaddresswrote in
news:IJB6i.15907$j63.14395@newsread2.news.pas.eart hlink.net:
You arrogant dumb@$$. The OP is using the calculation as a default
value for his description field. He may alter or add to the
contents thereof. It is required in any sane MRP or equivalent
system.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

You arrogant dumb@$$. Whoever taught you to put a calculated value in a
table? What happens if a user changes the length, width or height and
doesn't bother to change the description? It doesn't change on its own!!! In
case you are not smart enough, the result is that the description does not
match the data in the length, width and height fields!!!!!

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
resource@pcdatasheet.com






"Bob Quintal" <rquintal@sPAmpatico.cawrote in message
news:Xns993EBC850E005BQuintal@66.150.105.47...

You arrogant dumb@$$.

I just came across the following in the Microsoft.Public.Access. Forms
newsgoup. Do you also have the same arrogant comment about all these
responders too?

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
resource@pcdatasheet.com




By OP ----- What must I do to save the total?

You must do nothing at all. It's common sense not to store values from
totals. What you do is save the 'operants' and the outcome should be
calculated as you did via a textfield or either a field in a query. When
using a query you don;t have to look in the table because you don't save the
calculation.
--
Maurice Ausum

Is there a reason you need to store the total amount in the table, though?
Can't you just calculate the total from the other fields, thereby negating
the need to redundantly store the total?

--

Ken Snell
<MS ACCESS MVP>

Generally, you should not store calculated values ... what happens if one of
the root values change, and (for some reason) the total doesn't get updated?
Since you're obviously storing the root values, just calculate the
TotalAmount when needed, using the formula you list above.

Scott McDaniel

Don't.

Storing derived data such as this in your table accomplishes
three things: it wastes disk space; it wastes time (almost
any calculation will be MUCH faster than a disk fetch); and
most importantly, it risks data corruption. If one of the
underlying fields is subsequently edited, you will have data
in your table WHICH IS WRONG, and no automatic way to detect
that fact.

Just redo the calculation whenever you need it, either as a
calculated field in a Query or just as you're now doing it -
in the control source of a Form or a Report textbox.

John W. Vinson [MVP]

You have received a lot of good advice. Pay particular attention to Johm
Vinson. His comment pretty much covers it.
------
Dave Hargis, Microsoft Access MVP


Thanks to you all.

I will not save the total.
I will not save the total.
I will not save the total.

Seriously, I appreciate all your input.

By OP ------







"Bob Quintal" <rquintal@sPAmpatico.cawrote in message
news:Xns993EBC850E005BQuintal@66.150.105.47...

"Steve" <sorry@private.emailaddresswrote
Steve, you perhaps should read a full discussion on "calculated fields in
tables". There are cases, such as a calculated cost, in which the factors
may change, but the cost is set and stays the same. The way it goes is, "any
calculation which can be reproduced when needed should not be stored in the
table."

From the posts I see, there's not enough information about the situation for
either you or Bob to make the strong statements you've each made, as though
they were fact. And, whether or not your descriptions of each other are
accurate, I'd personally appreciate it if you would control your emotions
and reduce the nastiness.

Larry Linson

"Bob Quintal" <rquintal@sPAmpatico.cawrote
Bob, "any calculation which can be reproduced when needed should not be
stored in the table." From the posts I see, there's not enough information
about the situation for either you or Steve to make the strong statements
you've each made, as though they were fact. And, whether or not your
descriptions of each other are accurate, I'd personally appreciate it if you
would control your emotions and reduce the nastiness.

Larry Linson

Hi Larry,

Nastiness is 'in the air' starting from the very moment that Steve is 'back'.
It is very nasty and disappointing to see him advertising again.
In fact it is a bloody shame !!
I do hope we can reduce the nastiness indeed.

Arno R

On May 29, 9:03 am, "Arno R" <arracomn_o_s_p_...@planet.nlwrote:Ok, Thanks for all answers. I'm pretty new to this.
I need both the original sizes and the changed sizes.
I will then compare and see how much has been given away (as a
discount).

Regarding the discription I just really want the user to be able to
enter whatever he wants. But by default according to sizes.

L

"Larry Linson" <bouncer@localhost.notwrote in
news:PSK6i.644$d63.283@trnddc06:
Hi Larry, I will agree that a true calculated value (the sum of
po line values, e.g.) should always be calculated, but a desc
(ription) field, as the original poster named the target of his
calculation, is one of the places where the rule should never
apply.

I've worked MRP systems long enough to know that not all entries
will obey the rule, and that when you have 24 entries for a
material that is 4ft x 8ft x 1/2in you are going to want to add
other words to that description, like plywood, particle board,
gypsum board....Populating part of a description field from
other data entities is a wise way of automating the data entry
task..
..

Besides, there are good reasons to "denormalize" a table.
http://fox.wikis.com/wc.dll?
Wiki~SpecificReasonsToDenormalize~SoftwareEng
http://safari.oreilly.com/078972569X/ch04lev1sec3

I would not even classify this instance as a denormalization.

As to PCD (Pretty Crappy Developer) posting his supercilious and
often misleading suggestions, along with his blatantly violating
the rule of "No Advertizing" with his tagline, I asked him
before to "Go Away, don't go away mad, just go away.". He was
gone for a long while, and things were peaceful. He comes back,
and in the first two responses here, he gives wrong answers. At
least he's consistent.

--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

"Steve" <sorry@private.emailaddresswrote in message
news:IJB6i.15907$j63.14395@newsread2.news.pas.eart hlink.net...My take on this is that the OP wants the calculated value to be the default
description which the user can then edit if they wish.

Keith.