I'm working on an app that records data collected by service
technicians (VB.Net front-end, SQL Server 2000 back end). The
technicians need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as 123.1
and a third as 1.32456.
That's fine - those can be saved as floating point numbers (very
little math is done with these numbers so I'm not too worried about
strange floating point results). The problem is that I can't come up
with a good way to save trailing zeros. If the technician records a
reading of 12.00 or 15.560 for example, it needs to be preserved with
the trailing zeros. I can make the numbers display correctly in the
front end when they are typed in, but when they're saved, SQL Server
drops the trailing zero(s). That means that when they're retrieved
from the DB the next time they're needed, there is no way to know how
many zeros to display (e.g. the tech may have typed in 12.00, but after
it's been saved and retrieved it comes back as 12 and there's no
way to know if the tech originally type it in as 12 or 12.0 or 12.000).
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
Putting numbers in text fields (option 1) makes me nervous and option 2
seems like a ton of extra work. Does anyone have a better idea or a
recommendation for option 1 or option 2?
9  8658 
Chester, take a look at the decimal and numeric data types in SQL Server
Books Online. You can specify the precision (total number of digits the
field can contain), and scale (the number of digits to the right of the
decimal place).
Tom Dacon
Dacon Software Consulting
"Chester" <ct******@netsc ape.netwrote in message
news:11******** *************@7 3g2000cwn.googl egroups.com...
I'm working on an app that records data collected by service
technicians (VB.Net front-end, SQL Server 2000 back end). The
technicians need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as 123.1
and a third as 1.32456.
That's fine - those can be saved as floating point numbers (very
little math is done with these numbers so I'm not too worried about
strange floating point results). The problem is that I can't come up
with a good way to save trailing zeros. If the technician records a
reading of 12.00 or 15.560 for example, it needs to be preserved with
the trailing zeros. I can make the numbers display correctly in the
front end when they are typed in, but when they're saved, SQL Server
drops the trailing zero(s). That means that when they're retrieved
from the DB the next time they're needed, there is no way to know how
many zeros to display (e.g. the tech may have typed in 12.00, but after
it's been saved and retrieved it comes back as 12 and there's no
way to know if the tech originally type it in as 12 or 12.0 or 12.000).
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
Putting numbers in text fields (option 1) makes me nervous and option 2
seems like a ton of extra work. Does anyone have a better idea or a
recommendation for option 1 or option 2?
I am at a loss as to why you would be nervous about "Putting numbers in text
fields".
I'll bet you dollars to donuts that the technicians are typing the values
into a TextBox control which is nothing more than a 'text field as you put
it. Therefore, whatever validation you have on those textboxes will suffice.
In the database tables, make sure that you declare the columns with enough
width to cater for the maximum length of a number that a technician can
enter, i.e. maximum number of integral digits + maximum number of decimal
digits + 1 (for the decimal point) + 1 (for a sign, if necessary).
If you need to do math on the values stored in the database then in your SQL
statments, cast the varchar or nvarchar value as a float first, e.g.:
select sum(cast(<colum nnameas float))'.
If you need to do any math on aany of the values in your application then
all you need to do is cast the string as a Decimal, Single or Double (I
recommend Decimal), e.g.:
Dim _x As Decimal = Decimal.Parse(v alue)
For validation, I would recommend using the Decimal.TryPars e method. You
obviously don't care what the value is so long as it can be sucessfully
converted to a Decimal.
An aspect that you do need to consider is whether or not there are any
'outside agencies' that insert these values into the database. If so, then
they wiull have to brought into line as well. Likewise any 'outside
agencies' that use these values from the database will also need to be told
how to interpret the values.
"Chester" <ct******@netsc ape.netwrote in message
news:11******** *************@7 3g2000cwn.googl egroups.com...
I'm working on an app that records data collected by service
technicians (VB.Net front-end, SQL Server 2000 back end). The
technicians need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as 123.1
and a third as 1.32456.
That's fine - those can be saved as floating point numbers (very
little math is done with these numbers so I'm not too worried about
strange floating point results). The problem is that I can't come up
with a good way to save trailing zeros. If the technician records a
reading of 12.00 or 15.560 for example, it needs to be preserved with
the trailing zeros. I can make the numbers display correctly in the
front end when they are typed in, but when they're saved, SQL Server
drops the trailing zero(s). That means that when they're retrieved
from the DB the next time they're needed, there is no way to know how
many zeros to display (e.g. the tech may have typed in 12.00, but after
it's been saved and retrieved it comes back as 12 and there's no
way to know if the tech originally type it in as 12 or 12.0 or 12.000).
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
Putting numbers in text fields (option 1) makes me nervous and option 2
seems like a ton of extra work. Does anyone have a better idea or a
recommendation for option 1 or option 2?
And how would that help him?
"Tom Dacon" <To*@dacons.com wrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..
Chester, take a look at the decimal and numeric data types in SQL Server
Books Online. You can specify the precision (total number of digits the
field can contain), and scale (the number of digits to the right of the
decimal place).
Tom Dacon
Dacon Software Consulting
"Chester" <ct******@netsc ape.netwrote in message
news:11******** *************@7 3g2000cwn.googl egroups.com...
>I'm working on an app that records data collected by service
technicians (VB.Net front-end, SQL Server 2000 back end). The
technicians need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as 123.1
and a third as 1.32456.
That's fine - those can be saved as floating point numbers (very
little math is done with these numbers so I'm not too worried about
strange floating point results). The problem is that I can't come up
with a good way to save trailing zeros. If the technician records a
reading of 12.00 or 15.560 for example, it needs to be preserved with
the trailing zeros. I can make the numbers display correctly in the
front end when they are typed in, but when they're saved, SQL Server
drops the trailing zero(s). That means that when they're retrieved
from the DB the next time they're needed, there is no way to know how
many zeros to display (e.g. the tech may have typed in 12.00, but after
it's been saved and retrieved it comes back as 12 and there's no
way to know if the tech originally type it in as 12 or 12.0 or 12.000).
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
Putting numbers in text fields (option 1) makes me nervous and option 2
seems like a ton of extra work. Does anyone have a better idea or a
recommendati on for option 1 or option 2?
"Chester" <ct******@netsc ape.netwrote:
>I'm working on an app that records data collected by service
technicians (VB.Net front-end, SQL Server 2000 back end). The
technicians need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as 123.1
and a third as 1.32456.
My instinct would be to store them as (6345,2) and (1231,1) and
(132456,5). That way you preserve all information, and your database
keeps numbers rather than strings, and it's an easy calculation to
turn one of these pairs back into a float.
--
Lucian
Well, other than the fact that it specifically addresses his
requirement...w hat more would you want?
Tom Dacon
Dacon Software Consulting
"Stephany Young" <noone@localhos twrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..
And how would that help him?
"Tom Dacon" <To*@dacons.com wrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..
>Chester, take a look at the decimal and numeric data types in SQL Server
Books Online. You can specify the precision (total number of digits the
field can contain), and scale (the number of digits to the right of the
decimal place).
Tom Dacon
Dacon Software Consulting
"Chester" <ct******@netsc ape.netwrote in message
news:11******* **************@ 73g2000cwn.goog legroups.com...
>>I'm working on an app that records data collected by service
technicians (VB.Net front-end, SQL Server 2000 back end). The
technicians need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as 123.1
and a third as 1.32456.
That's fine - those can be saved as floating point numbers (very
little math is done with these numbers so I'm not too worried about
strange floating point results). The problem is that I can't come up
with a good way to save trailing zeros. If the technician records a
reading of 12.00 or 15.560 for example, it needs to be preserved with
the trailing zeros. I can make the numbers display correctly in the
front end when they are typed in, but when they're saved, SQL Server
drops the trailing zero(s). That means that when they're retrieved
from the DB the next time they're needed, there is no way to know how
many zeros to display (e.g. the tech may have typed in 12.00, but after
it's been saved and retrieved it comes back as 12 and there's no
way to know if the tech originally type it in as 12 or 12.0 or 12.000).
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
Putting numbers in text fields (option 1) makes me nervous and option 2
seems like a ton of extra work. Does anyone have a better idea or a
recommendatio n for option 1 or option 2?
If he uses, the decimal or numeric Sql Server datatype, how do you suggest
he retain the trailing zeroes of the values exactly as they were entered?
"Tom Dacon" <td****@communi ty.nospamwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..
Well, other than the fact that it specifically addresses his
requirement...w hat more would you want?
Tom Dacon
Dacon Software Consulting
"Stephany Young" <noone@localhos twrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..
>And how would that help him?
"Tom Dacon" <To*@dacons.com wrote in message
news:%2******* *********@TK2MS FTNGP03.phx.gbl ...
>>Chester, take a look at the decimal and numeric data types in SQL Server
Books Online. You can specify the precision (total number of digits the
field can contain), and scale (the number of digits to the right of the
decimal place).
Tom Dacon
Dacon Software Consulting
"Chester" <ct******@netsc ape.netwrote in message
news:11****** *************** @73g2000cwn.goo glegroups.com.. .
I'm working on an app that records data collected by service
technician s (VB.Net front-end, SQL Server 2000 back end). The
technician s need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as 123.1
and a third as 1.32456.
That's fine - those can be saved as floating point numbers (very
little math is done with these numbers so I'm not too worried about
strange floating point results). The problem is that I can't come up
with a good way to save trailing zeros. If the technician records a
reading of 12.00 or 15.560 for example, it needs to be preserved with
the trailing zeros. I can make the numbers display correctly in the
front end when they are typed in, but when they're saved, SQL Server
drops the trailing zero(s). That means that when they're retrieved
from the DB the next time they're needed, there is no way to know how
many zeros to display (e.g. the tech may have typed in 12.00, but after
it's been saved and retrieved it comes back as 12 and there's no
way to know if the tech originally type it in as 12 or 12.0 or 12.000).
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
Putting numbers in text fields (option 1) makes me nervous and option 2
seems like a ton of extra work. Does anyone have a better idea or a
recommendati on for option 1 or option 2?
Why do you have a problem storing them as text? Especially
if you're not going to do calculations on them, or try to
format them all into the same format. You can always convert
them to decimal or float when/if you need to. In the meantime,
you have exactly what the original technician input.
If you needed to do calcs, you could always store them both
ways, assuming you don't have 10 million rows and 200 columns
or something huge like that.
I would definitely do some validation to make sure the result
is numeric, if that's definitely a condition.
Robin S.
------------
"Chester" <ct******@netsc ape.netwrote in message
news:11******** *************@7 3g2000cwn.googl egroups.com...
I'm working on an app that records data collected by service
technicians (VB.Net front-end, SQL Server 2000 back end). The
technicians need to record numbers with varying scale and precision.
For example, they may record one reading as 63.45 and the next as
123.1
and a third as 1.32456.
That's fine - those can be saved as floating point numbers (very
little math is done with these numbers so I'm not too worried about
strange floating point results). The problem is that I can't come up
with a good way to save trailing zeros. If the technician records a
reading of 12.00 or 15.560 for example, it needs to be preserved with
the trailing zeros. I can make the numbers display correctly in the
front end when they are typed in, but when they're saved, SQL Server
drops the trailing zero(s). That means that when they're retrieved
from the DB the next time they're needed, there is no way to know how
many zeros to display (e.g. the tech may have typed in 12.00, but
after
it's been saved and retrieved it comes back as 12 and there's no
way to know if the tech originally type it in as 12 or 12.0 or
12.000).
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with
which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
Putting numbers in text fields (option 1) makes me nervous and option
2
seems like a ton of extra work. Does anyone have a better idea or a
recommendation for option 1 or option 2?
Thanks for all the good advice! I've done some more testing since the
original post and have elected to go the text route. The store-as-text
solution is going to be the easiest to reach from where I am now and
the most widely applicable. Stephany brought up a good point about
'outside agencies' and (fortunately) there are non to worry about
in this case. So I only have myself to blame if the app ends up trying
to do something like (12.87 * kilograms). Looks like I'll have to be
extra diligent about verification.
My reluctance was based on all the problems I've had with systems
that stored numbers as text but didn't tightly control the input and
so ended up with letters where there should only be number, etc.
Thanks again and happy VBing.
Chester
"Chester" <ct******@netsc ape.netwrote in news:1166228854 .395329.51560@
73g2000cwn.goog legroups.com:
The only ideas I've come up with are:
1) Save the numbers as text (varchar) and have stringent validation to
make sure that no text actually sneaks in.
2) Save the numbers as floating point AND save the precision with which
they were entered (e.g. 12.00 would get saved as 12 and the precision
would be saved as 2).
You should handle the decimals during output - You can use Number.ToString
("0.000000") to output it with 6 decimal places). This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Alberto Vera |
last post by:
Hello:
I have the next structure:
How Can I make it using Python?
How Can I update the value of 6?
|
by: Keali |
last post by:
for example:
A1 = 123
A1=123000 <- final result
A1 =1234
A1=123400<- final result
A1=1
A1=100000<-final result
|
by: tpcolson |
last post by:
I have a fairly large access 2003 table (200,000) records. Field 'X' is
a text field, and contains either no value, 4 digits, 5 digits, or 6
digits. What I need to do is to add two zeros to the left of the
records with 4 digits in field 'X', 1 zero to the left of the records
with 5 digits in field 'X', and 6 digits for nulls. IE, record 1 field
'X' contains 1234, after this magic, it would contain 001234. Bear in
mind, I have ABSOLUTLY...
|
by: Bob |
last post by:
I'm about to convert to string and use regex, but I thought there must be
something I'm missing here that already exists.
Bob
|
by: rsine |
last post by:
I am developing a program that requires me to read a string of data from
a text field in a database. Data is parsed from the string based upon a
starting position/length. If a piece of data doesn't meet the required
field length, then spaces are added, thus my issue. It appears VB.net
is trimming any trailing spaces. What should be a 250 character data
string is only 243 (less 7 trailing spaces). Is there a way to get this
to stop? I...
| | |
by: Albert |
last post by:
This isn't entirely related to C, but Kernighan and Ritchie asks in
Execise 1-18 of their C programming language book to 'Write a program
to remove trailing blanks and tabs from each line of input, and to
delete entirely blank lines'. What do they mean by trailing?
|
by: JimmyKoolPantz |
last post by:
Task: Customer wants a script of the data that was processed in a
"CSV" file.
Problem: Zip-Code leading zeros are dropped
Basically we have a client that has requested a custom script for each
file that he has us process. He wants this in a Comma Delimited
Format.
|
by: ManuelValdez |
last post by:
Hello everybody!
I need your valuable help to get an Excel macro to delete the single zeros only and no the zeros containing numbers like 360, 90, etc., because if I chose the search and replace in the Edit option, then all the zeros containing the numbers 360, 90, 502, etc. will be deleted.
Some nice person helped me with the following code to delete the zeros:
Selection.Replace What:="0", Replacement:="" , but unfortunately this code...
|
by: brian.j.parker |
last post by:
Hey all, I've noticed an obscure little quirk: it appears that if you
use a login with trailing spaces on the name, SYSTEM_USER
automatically trims those trailing spaces in SQL Server 2000, but not
SQL Server 2005.
Anybody know if this change in behavior is documented? If it is
intentional?
Is there a "quick fix" to revert to the old behavior (to automatically
RTRIM the results of SYSTEM_USER in 2005) until code can be changed?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
