Can't get significant digits of both "digits" and "largedigits"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. output csv for any BAF file containing records that have both a digits
field and a largedigits field along with the sigdigs field

What version of the product are you using? On what operating system?

1.3 on OpenBSD 4.5

Please provide any additional information below.

When using at least the following fields for output: sigdigs,digits,largedigits

The sigdigs field will contain the number of significant digits for either
of these fields.

If just the digits field has data (it contains the account code dialed by
the calling party) then the sigdigs field will list the significant digits
in this field.

If the largedigits field exists, then the sigdigs field contains the
significant digits for that field.  This field appears to contain the
number of the party making the call for certain circumstances.  I think it
may be sent by the calling party's phone system as caller id data even if
the originatingnpa is different (like if it is the trunk number of a PRI).

The problem is that if BOTH digits and largedigits have data in them, then
sigdigs can only contain the data for one of them, and it ends up being for
largedigits.

This is a problem because the account code in the digits field could have a
significant 0 in front of it, but it is a zero padded field.  So if the
actual account code is '04' you have no way of knowing that it wasn't just
'4' without the sigdigs field.

Is there not some way to have both sigdigs and siglargedigs fields?

Original issue reported on code.google.com by th...@bendtel.net on 22 Dec 2009 at 9:30

[GoogleCodeExporter]

If you use regular file output does the sigdigs and digits print out right?

If so then you may be onto a significant bug.. Problem is the modules that can 
end up
attached to certain records share field names.  It might be the case that when 
you
request a type name in csv it reads only 1 of those fields, even though 2 
fields with
that name exist.

Very problematic if that is the case

Original comment by charless...@gmail.com on 22 Dec 2009 at 9:43

• Added labels: OpSys-All, Priority-High, Usability
• Removed labels: Priority-Medium

[GoogleCodeExporter]

> If you use regular file output does the sigdigs and digits print out right?

Yes, It will look like this at the end of the record:

Module Code: 164
Number Identity: Originating CPN
Country Code or Data Network ID Code: E.164 Number, 1 Digit Code : 0001
Significant Digits in Next Field: 010
Digits: 1235551234
Module Code: 103
Significant Digits in Next Field: 003
Digits: 000000000000123
Module Code: 000

Module 103 is always where I have gotten the account code from.  It took me a 
while
to find the field name for it. I'm not sure if it ever contains any other data. 
 The
largedigits field is also important for me because I use it as the calling 
number if
it exists.

Original comment by th...@bendtel.net on 22 Dec 2009 at 10:04

[GoogleCodeExporter]

I've been giving this a little bit of thought, and a couple of things would 
make it
convenient (at least from a user's perspective).  Perhaps if there was an 
associative
array of sigdigs so that sigdigs[digits] could be selected.  Or if the sigdigs 
could
be retained and made part of digits and largedigits so that they were an 
attribute of
the object, and then one could select digits.sigdigs().  Then the interface 
could
just know how to do this for the user...  I'm not sure how hard this would be 
on the
current design, though; I haven't looked at the code that hard.

Original comment by th...@bendtel.net on 26 Dec 2009 at 12:24

[GoogleCodeExporter]

Its a good idea, but the way baf files are laid out there are no relationships
between fields.  Even though this is an obvious relationship, building 
something like
that would require a bit of post processing and more extensive field defines.
Even if that is done doing such a thing would put constraints on the file 
format, now
that certain fields have relationships with other fields, some very strict 
rules must
govern the file format.  This would normally not be a big problem except I have 
no
control over that format.
Its a good idea but I do not think its the best solution.

I have actually not liked the way I handle modules for a while.  Modules are 
like
mini-records, only any number of them can be attached to any record.  Trouble 
occurs
when they have a field with the same name as one in the record.  Maybe what I 
can do
is change the field name for modules to something like
m160.sigdigs
so you would use that in your csv types list to specify the specific module 
field.  

Original comment by charless...@gmail.com on 26 Dec 2009 at 1:54

• Changed state: Accepted

[GoogleCodeExporter]

I committed some changes that do 2 things.  First, all module fields are 
identified
by m[number].fieldname now, so if you sigdigs are in module 103, the name to 
use for
cvs or sql would be m103.sigdigs

I also modified file output to print out the field type id, which is the string 
you
can use when describing cvs fields or sql values.  Like i said in the commit, 
this
should have done a while ago, I do not know why it just crossed my mind now..

Let me know if this solution is reasonable.

Original comment by charless...@gmail.com on 4 Jan 2010 at 3:38

• Changed state: Fixed

[GoogleCodeExporter]

Awesome!  With latest code (2009-01-04) I can now do this:

bafprp -rcsv -lfile -efile -prfilename:output4.txt -pefilename:bafprp.err
-plfilename:bafprp.log
-prfields:m103.sigdigs,m103.digits,m164.sigdigs,m164.largedigits 
BAF_something.pri

This will give me my account code data and m164 data!

Thanks so much!

Original comment by th...@bendtel.net on 4 Jan 2010 at 6:01

[GoogleCodeExporter]

no problem, glad it works

Original comment by charless...@gmail.com on 4 Jan 2010 at 7:22

• Changed state: Verified