BR Forum

Hi all,

I have a "member" data file where the name and address are currently stored all in upper case in "C" fields. The name field is C 25 and names are entered in "LastName, FirstName MI" format.

I plan to separate these name components into individual fields AND make them mixed case instead of forcing upper case. I'm also going to mix the case of the address fields. I was going to use "V" fields to automatically trim the trailing spaces. Currently, they are all "C" fields, as I mentioned.

The issue is keyed file access. One of the secondary keys is Name/MemberNo. So the new key would have to be LastName/FirstName/MI/MemberNo. With V fields, am I correct in assuming that the components of the key would NOT automatically be padded out (by BR) with trailing spaces when the key is created? So in other words, my key would be junk because the "columns" wouldn't line up in the key?

In my case, would the better choice be to continue to use "C" fields for any components that might ultimately become part of a key? Or should I create an additional key field inside the record (invisible to the user) that is LastName/FirstName/MI/MemberNo with the padding of the individual components?

What is the appropriate use of "V" fields? I have NEVER used them in the past, always defaulting to "C" for character fields. I'm rewriting a lot of my application and this is the time for these types of changes if they make sense.

-- Susan

Upon further reading, I THINK that I understand that "V" fields are still stored in the file WITH the trailing spaces and the spaces are trimmed when you READ the data in. Is that right? And if so, then specifying a key start/end position DOES include those trailing spaces.

Secondly, if "V" is used just when you're reading data in, does it matter if you wrote those values out to the file as "C"s? In that case, I wouldn't need to convert my data to "V" at all...just change the read statement. Am I on the right track?

I wonder how I missed this all these years... Later, I'll have to move on to "B" fields. Most of my data consists of "C", "PD" and "N". I bet I'm missing out on some great stuff.

-- Susan


Susan Smith wrote:

Hi all,

I have a "member" data file where the name and address are currently stored all in upper case in "C" fields. The name field is C 25 and names are entered in "LastName, FirstName MI" format.

I plan to separate these name components into individual fields AND make them mixed case instead of forcing upper case. I'm also going to mix the case of the address fields. I was going to use "V" fields to automatically trim the trailing spaces. Currently, they are all "C" fields, as I mentioned.

The issue is keyed file access. One of the secondary keys is Name/MemberNo. So the new key would have to be LastName/FirstName/MI/MemberNo. With V fields, am I correct in assuming that the components of the key would NOT automatically be padded out (by BR) with trailing spaces when the key is created? So in other words, my key would be junk because the "columns" wouldn't line up in the key?

In my case, would the better choice be to continue to use "C" fields for any components that might ultimately become part of a key? Or should I create an additional key field inside the record (invisible to the user) that is LastName/FirstName/MI/MemberNo with the padding of the individual components?

What is the appropriate use of "V" fields? I have NEVER used them in the past, always defaulting to "C" for character fields. I'm rewriting a lot of my application and this is the time for these types of changes if they make sense.

-- Susan

_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net

The V field right trims a field that is read. The format of the field within the file is the same whether written with C 30 or V 30 so you don’t have a problem. If you were writing to unformatted internal files it would be a different story because the field would in fact be trimmed, however, indexing an unformatted internal file is generally NOT a thing that you would want to attempt.

To see the effect of reading and writing V vs C fields try a simple program that writes 10 records formatted with C 20 and write the alphabet into each record (at least the first 20 characters, then go back and rewrite each record using the V 20 parameter and insert numbers

For a=1 to 10
Rewrite #X,using “FOMR V 20”:Str$(1**a)
Next a

Then restore the file and read using the C 20 parameter and print each record to the screen.



George L. Tisdale, CPA
Tisdale CPA
75 Junction Square Drive
Concord, MA 01742
(978) 369-5585
IRS Circular 230 Notice: "To ensure compliance with requirements imposed by the IRS, we inform you that any U.S. tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein."
This electronic message transmission contains information which is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination or distribution of this communication to other than the intended recipient is strictly prohibited. If you have received this communication in error, please notify us immediately by calling (978) 369-5585 or by electronic mail (gtisdale@tisdalecpa.com) Thank you.


From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of Susan Smith
Sent: Sunday, May 24, 2009 10:39 AM
To: BR Forum
Subject: [BR_forum] Index Files and "V" fields



Hi all,

I have a "member" data file where the name and address are currently stored all in upper case in "C" fields. The name field is C 25 and names are entered in "LastName, FirstName MI" format.

I plan to separate these name components into individual fields AND make them mixed case instead of forcing upper case. I'm also going to mix the case of the address fields. I was going to use "V" fields to automatically trim the trailing spaces. Currently, they are all "C" fields, as I mentioned.

The issue is keyed file access. One of the secondary keys is Name/MemberNo. So the new key would have to be LastName/FirstName/MI/MemberNo. With V fields, am I correct in assuming that the components of the key would NOT automatically be padded out (by BR) with trailing spaces when the key is created? So in other words, my key would be junk because the "columns" wouldn't line up in the key?

In my case, would the better choice be to continue to use "C" fields for any components that might ultimately become part of a key? Or should I create an additional key field inside the record (invisible to the user) that is LastName/FirstName/MI/MemberNo with the padding of the individual components?

What is the appropriate use of "V" fields? I have NEVER used them in the past, always defaulting to "C" for character fields. I'm rewriting a lot of my application and this is the time for these types of changes if they make sense.

-- Susan

Thanks George. Now that I know that "V" fields only trim for reading strings$, that opens up a whole new world. I am constantly "trim$-ing" everything after I read it. Now I can just go back and update my form statements and replace the "C" reads with "V" reads and not have any effect on the data in the files at all. Very cool.

Sometimes I think I need to go back an repeat the Business Rules 101 course. I was obviously absent on some of those days the first time! And this is also where it's handy to have a printed manual all in one piece because you can read it from start to finish to learn those things that fell through the cracks.

-- Susan


George Tisdale wrote:

<![endif]--> <![endif]-->
The V field right trims a field that is read. The format of the field within the file is the same whether written with C 30 or V 30 so you don’t have a problem. If you were writing to unformatted internal files it would be a different story because the field would in fact be trimmed, however, indexing an unformatted internal file is generally NOT a thing that you would want to attempt.

To see the effect of reading and writing V vs C fields try a simple program that writes 10 records formatted with C 20 and write the alphabet into each record (at least the first 20 characters, then go back and rewrite each record using the V 20 parameter and insert numbers

For a=1 to 10
Rewrite #X,using “FOMR V 20”:Str$(1**a)
Next a

Then restore the file and read using the C 20 parameter and print each record to the screen.



George L. Tisdale, CPA



From: br_forum-bounces@ads.net (br_forum-bounces@ads.net) [mailto:br_forum-bounces@ads.net (br_forum-bounces@ads.net)] On Behalf Of Susan Smith
Sent: Sunday, May 24, 2009 10:39 AM
To: BR Forum
Subject: [BR_forum] Index Files and "V" fields



Hi all,

I have a "member" data file where the name and address are currently stored all in upper case in "C" fields. The name field is C 25 and names are entered in "LastName, FirstName MI" format.

I plan to separate these name components into individual fields AND make them mixed case instead of forcing upper case. I'm also going to mix the case of the address fields. I was going to use "V" fields to automatically trim the trailing spaces. Currently, they are all "C" fields, as I mentioned.

The issue is keyed file access. One of the secondary keys is Name/MemberNo. So the new key would have to be LastName/FirstName/MI/MemberNo. With V fields, am I correct in assuming that the components of the key would NOT automatically be padded out (by BR) with trailing spaces when the key is created? So in other words, my key would be junk because the "columns" wouldn't line up in the key?

In my case, would the better choice be to continue to use "C" fields for any components that might ultimately become part of a key? Or should I create an additional key field inside the record (invisible to the user) that is LastName/FirstName/MI/MemberNo with the padding of the individual components?

What is the appropriate use of "V" fields? I have NEVER used them in the past, always defaulting to "C" for character fields. I'm rewriting a lot of my application and this is the time for these types of changes if they make sense.

-- Susan

Susan,

Bear in mind that the read using "V" fields only does the same as a
RTRM$ not the same as a TRIM$. That is if the field has leading spaces,
they will be left intact after doing a read with "V", but the trailing
spaces will be removed.

David Bohlke

Susan Smith wrote:

Thanks George. Now that I know that "V" fields only trim for *reading*
strings$, that opens up a whole new world. I am constantly "trim$-ing"
everything after I read it. Now I can just go back and update my form
statements and replace the "C" reads with "V" reads and not have any
effect on the data in the files at all. Very cool.

Sometimes I think I need to go back an repeat the Business Rules 101
course. I was obviously absent on some of those days the first time!
And this is also where it's handy to have a printed manual all in one
piece because you can read it from start to finish to learn those
things that fell through the cracks.

-- Susan


George Tisdale wrote:

The V field right trims a field that is read. The format of the field
within the file is the same whether written with C 30 or V 30 so you
don’t have a problem. If you were writing to unformatted internal
files it would be a different story because the field would in fact
be trimmed, however, indexing an unformatted internal file is
generally NOT a thing that you would want to attempt.

To see the effect of reading and writing V vs C fields try a simple
program that writes 10 records formatted with C 20 and write the
alphabet into each record (at least the first 20 characters, then go
back and rewrite each record using the V 20 parameter and insert numbers

For a=1 to 10

Rewrite #X,using “FOMR V 20”:Str$(1**a)

Next a

Then restore the file and read using the C 20 parameter and print
each record to the screen.

*George L. Tisdale, CPA*


*From:* br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net]
*On Behalf Of *Susan Smith
*Sent:* Sunday, May 24, 2009 10:39 AM
*To:* BR Forum
*Subject:* [BR_forum] Index Files and "V" fields

Hi all,

I have a "member" data file where the name and address are currently
stored all in upper case in "C" fields. The name field is C 25 and
names are entered in "LastName, FirstName MI" format.

I plan to separate these name components into individual fields AND
make them mixed case instead of forcing upper case. I'm also going to
mix the case of the address fields. I was going to use "V" fields to
automatically trim the trailing spaces. Currently, they are all "C"
fields, as I mentioned.

The issue is keyed file access. One of the secondary keys is
Name/MemberNo. So the new key would have to be
LastName/FirstName/MI/MemberNo. With V fields, am I correct in
assuming that the components of the key would NOT automatically be
padded out (by BR) with trailing spaces when the key is created? So
in other words, my key would be junk because the "columns" wouldn't
line up in the key?

In my case, would the better choice be to continue to use "C" fields
for any components that might ultimately become part of a key? Or
should I create an additional key field inside the record (invisible
to the user) that is LastName/FirstName/MI/MemberNo with the padding
of the individual components?

What is the appropriate use of "V" fields? I have NEVER used them in
the past, always defaulting to "C" for character fields. I'm
rewriting a lot of my application and this is the time for these
types of changes if they make sense.

-- Susan

------------------------------------------------------------------------

_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net

_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net

Oh! That's good to know, David. I wasn't aware of that. Generally I always TRIM$() everything so that I get both sides trimmed , but I suppose that most of the time an RTRM$() is adequate and therefore, "V" fields would do the trick. Thanks for the heads up. I'll keep that in mind. (as long as I'm capable of keeping ANYTHING in my mind, that is)

-- Susan

David Bohlke wrote:

Susan,

Bear in mind that the read using "V" fields only does the same as a RTRM$ not the same as a TRIM$. That is if the field has leading spaces, they will be left intact after doing a read with "V", but the trailing spaces will be removed.

David Bohlke

Susan Smith wrote:

Thanks George. Now that I know that "V" fields only trim for *reading* strings$, that opens up a whole new world. I am constantly "trim$-ing" everything after I read it. Now I can just go back and update my form statements and replace the "C" reads with "V" reads and not have any effect on the data in the files at all. Very cool.

Sometimes I think I need to go back an repeat the Business Rules 101 course. I was obviously absent on some of those days the first time! And this is also where it's handy to have a printed manual all in one piece because you can read it from start to finish to learn those things that fell through the cracks.

-- Susan


George Tisdale wrote:

The V field right trims a field that is read. The format of the field within the file is the same whether written with C 30 or V 30 so you don’t have a problem. If you were writing to unformatted internal files it would be a different story because the field would in fact be trimmed, however, indexing an unformatted internal file is generally NOT a thing that you would want to attempt.

To see the effect of reading and writing V vs C fields try a simple program that writes 10 records formatted with C 20 and write the alphabet into each record (at least the first 20 characters, then go back and rewrite each record using the V 20 parameter and insert numbers

For a=1 to 10

Rewrite #X,using “FOMR V 20”:Str$(1**a)

Next a

Then restore the file and read using the C 20 parameter and print each record to the screen.

*George L. Tisdale, CPA*


*From:* br_forum-bounces@ads.net (br_forum-bounces@ads.net) [mailto:br_forum-bounces@ads.net (br_forum-bounces@ads.net)] *On Behalf Of *Susan Smith
*Sent:* Sunday, May 24, 2009 10:39 AM
*To:* BR Forum
*Subject:* [BR_forum] Index Files and "V" fields

Hi all,

I have a "member" data file where the name and address are currently stored all in upper case in "C" fields. The name field is C 25 and names are entered in "LastName, FirstName MI" format.

I plan to separate these name components into individual fields AND make them mixed case instead of forcing upper case. I'm also going to mix the case of the address fields. I was going to use "V" fields to automatically trim the trailing spaces. Currently, they are all "C" fields, as I mentioned.

The issue is keyed file access. One of the secondary keys is Name/MemberNo. So the new key would have to be LastName/FirstName/MI/MemberNo. With V fields, am I correct in assuming that the components of the key would NOT automatically be padded out (by BR) with trailing spaces when the key is created? So in other words, my key would be junk because the "columns" wouldn't line up in the key?

In my case, would the better choice be to continue to use "C" fields for any components that might ultimately become part of a key? Or should I create an additional key field inside the record (invisible to the user) that is LastName/FirstName/MI/MemberNo with the padding of the individual components?

What is the appropriate use of "V" fields? I have NEVER used them in the past, always defaulting to "C" for character fields. I'm rewriting a lot of my application and this is the time for these types of changes if they make sense.

-- Susan

V does a RTRM$ just after the field is read. Your data does not need to be converted at all. Your keys will work fine, but when you build the key in your program you need to make sure you add the proper number of spaces back in. Because you were trimming just after you read the data anyway, you probably are already adding in those spaces when you build a key in code anyway.
 
B fields are binary fields. They store a number. There are many different types of Numeric Storage fields. I can't say that B is any better then PD. The only difference may be speed and storage space. I know the "N" format for storing a number is very wasteful of space. It converts the number to a string and writes it down using one byte for each digit. A "B" field is just binary a B 2 says "Use two bytes to store this number" (which gives you a range of -32,767 to + 32768).
 
In Linux a B field stores the high byte first, and in Windows a B field stores the low byte first. (or perhaps I have this backwards). But the point is, Linux based operating systems (including Mac OS (i think)) and Windows based operating systems read and write "B" fields differently.
 
Think about the Chinese reading from up to down and from right to left through the pages of the book.
 
Therefore, if you plan on having your same BR program run on both linux and windows simultaneously, then you will need to use "BH" or "BL" fields instead of B fields. BH fields do the same thing as B fields but force BR to always store the high byte first. BL fields store the Low byte first. Its important to use BH and BL, not B in order to make it so your programs are compatible with both linux and windows.
 
(The reason you might do this - BR runs faster on Linux but can display better graphics under Windows. Some BR companies use Windows BR running on a Samba share when they are at the office and use their Linux version of BR over Telnet when they are working remotely. (Telnet, while regrettably text only, is still the fastest way to access your BR programs over the Internet, unless you go all the way and make a BR Web Scripting Bridge powered Interactive Web Page)
 
I have no idea, however, if there is any advantage to using B over using PD or any other numeric field format. I can only imagine that using "N" is probably the slowest and most wasteful of space. But beyond N, I don't see the big advantage of using one numeric field over another. Could anyone else chime in and tell us any reasons to use one type of Numeric Data Storage format over Another?

Gabriel

 
On Sun, May 24, 2009 at 9:38 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:

Hi all,

I have a "member" data file where the name and address are currently stored all in upper case in "C" fields. The name field is C 25 and names are entered in "LastName, FirstName MI" format.

I plan to separate these name components into individual fields AND make them mixed case instead of forcing upper case. I'm also going to mix the case of the address fields. I was going to use "V" fields to automatically trim the trailing spaces. Currently, they are all "C" fields, as I mentioned.

The issue is keyed file access. One of the secondary keys is  Name/MemberNo. So the new key would have to be LastName/FirstName/MI/MemberNo. With V fields, am I correct in assuming that the components of the key would NOT automatically be padded out (by BR) with trailing spaces when the key is created? So in other words, my key would be junk because the "columns" wouldn't line up in the key?

In my case, would the better choice be to continue to use "C" fields for any components that might ultimately become part of a key? Or should I create an additional key field inside the record (invisible to the user) that is LastName/FirstName/MI/MemberNo with the padding of the individual components?

What is the appropriate use of "V" fields? I have NEVER used them in the past, always defaulting to "C" for character fields. I'm rewriting a lot of my application and this is the time for these types of changes if they make sense.

-- Susan


_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net

Thanks for bringing up the subject of numeric field formats. I have never really known why some people pick one over another. I read through the documentation about them and although I can follow it, I still don't understand the APPLICATION of that information. What does it mean in the real world and what types of data should be store in which formats? It used to be based on storage space. Now, that isn't so much a problem. And BECAUSE we can store so much more information now, perhaps formats that economize on SPEED are better choices, no?

All of my numeric fields are currently either PD or N.

I have never used "B" fields before, nor have I used "D", "G", "ZD", or Date fields such as DT,DL & DH. I really should acquaint myself with some of these things. My dates are all stored as either full YCMD dates in either PD fields or N fields. I see the benefit of using serial # dates instead, but I haven't converted any of my files to that format so far. I'd probably have a lot fewer mistakes of backwards dates in data files if I used serial# dates only.

-- Susan

Gabriel Bakker wrote:

V does a RTRM$ just after the field is read. Your data does not need to be converted at all. Your keys will work fine, but when you build the key in your program you need to make sure you add the proper number of spaces back in. Because you were trimming just after you read the data anyway, you probably are already adding in those spaces when you build a key in code anyway.

B fields are binary fields. They store a number. There are many different types of Numeric Storage fields. I can't say that B is any better then PD. The only difference may be speed and storage space. I know the "N" format for storing a number is very wasteful of space. It converts the number to a string and writes it down using one byte for each digit. A "B" field is just binary a B 2 says "Use two bytes to store this number" (which gives you a range of -32,767 to + 32768).

In Linux a B field stores the high byte first, and in Windows a B field stores the low byte first. (or perhaps I have this backwards). But the point is, Linux based operating systems (including Mac OS (i think)) and Windows based operating systems read and write "B" fields differently.

Think about the Chinese reading from up to down and from right to left through the pages of the book.

Therefore, if you plan on having your same BR program run on both linux and windows simultaneously, then you will need to use "BH" or "BL" fields instead of B fields. BH fields do the same thing as B fields but force BR to always store the high byte first. BL fields store the Low byte first. Its important to use BH and BL, not B in order to make it so your programs are compatible with both linux and windows.

(The reason you might do this - BR runs faster on Linux but can display better graphics under Windows. Some BR companies use Windows BR running on a Samba share when they are at the office and use their Linux version of BR over Telnet when they are working remotely. (Telnet, while regrettably text only, is still the fastest way to access your BR programs over the Internet, unless you go all the way and make a BR Web Scripting Bridge powered Interactive Web Page)

I have no idea, however, if there is any advantage to using B over using PD or any other numeric field format. I can only imagine that using "N" is probably the slowest and most wasteful of space. But beyond N, I don't see the big advantage of using one numeric field over another. Could anyone else chime in and tell us any reasons to use one type of Numeric Data Storage format over Another?

Gabriel

If you use BH or BL you don't need to be concerned with native byte sequence.

The issue is not Windows vs Linux. It is Intel vs non-Intel. Intel (and knock-offs) store binary data in low to high (unnatural) order, whereas IBM and Motorola chips store bytes in high to low (natural) order.

BH and BL override the native byte order.

gordon





On Mon, May 25, 2009 at 12:59 PM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:

Thanks for bringing up the subject of numeric field formats. I have never really known why some people pick one over another. I read through the documentation about them and although I can follow it, I still don't understand the APPLICATION of that information. What does it mean in the real world and what types of data should be store in which formats? It used to be based on storage space. Now, that isn't so much a problem. And BECAUSE we can store so much more information now, perhaps formats that economize on SPEED are better choices, no?

All of my numeric fields are currently either PD or N.

I have never used "B" fields  before, nor have I used "D", "G", "ZD", or Date fields such as DT,DL & DH. I really should acquaint myself with some of these things. My dates are all stored as either full YCMD dates in either PD fields or N fields. I see the benefit of using serial # dates instead, but I haven't converted any of my files to that format so far. I'd probably have a lot fewer mistakes of backwards dates in data files if I used serial# dates only.

-- Susan

Gabriel Bakker wrote:

V does a RTRM$ just after the field is read. Your data does not need to be converted at all. Your keys will work fine, but when you build the key in your program you need to make sure you add the proper number of spaces back in. Because you were trimming just after you read the data anyway, you probably are already adding in those spaces when you build a key in code anyway.
 
B fields are binary fields. They store a number. There are many different types of Numeric Storage fields. I can't say that B is any better then PD. The only difference may be speed and storage space. I know the "N" format for storing a number is very wasteful of space. It converts the number to a string and writes it down using one byte for each digit. A "B" field is just binary a B 2 says "Use two bytes to store this number" (which gives you a range of -32,767 to + 32768).
 
In Linux a B field stores the high byte first, and in Windows a B field stores the low byte first. (or perhaps I have this backwards). But the point is, Linux based operating systems (including Mac OS (i think)) and Windows based operating systems read and write "B" fields differently.
 
Think about the Chinese reading from up to down and from right to left through the pages of the book.
 
Therefore, if you plan on having your same BR program run on both linux and windows simultaneously, then you will need to use "BH" or "BL" fields instead of B fields. BH fields do the same thing as B fields but force BR to always store the high byte first. BL fields store the Low byte first. Its important to use BH and BL, not B in order to make it so your programs are compatible with both linux and windows.
 
(The reason you might do this - BR runs faster on Linux but can display better graphics under Windows. Some BR companies use Windows BR running on a Samba share when they are at the office and use their Linux version of BR over Telnet when they are working remotely. (Telnet, while regrettably text only, is still the fastest way to access your BR programs over the Internet, unless you go all the way and make a BR Web Scripting Bridge powered Interactive Web Page)
 
I have no idea, however, if there is any advantage to using B over using PD or any other numeric field format. I can only imagine that using "N" is probably the slowest and most wasteful of space. But beyond N, I don't see the big advantage of using one numeric field over another. Could anyone else chime in and tell us any reasons to use one type of Numeric Data Storage format over Another?

Gabriel

_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net

My personal preference is for BH.

I know that in some environments, it will be a “Tad Slower”, but it always sorts correctly, even when referred to as a character field.


Luis I. Gomez
GomezL@CollectionSoftware.com (GomezL@CollectionSoftware.com)
1-800-435-7257
Commercial Legal Software, Inc.
http://www.CollectionSoftware.com

From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of Gordon Dye
Sent: Tuesday, May 26, 2009 2:47 PM
To: Business Rules Forum
Subject: Re: [BR_forum] Index Files and "V" fields


If you use BH or BL you don't need to be concerned with native byte sequence.

The issue is not Windows vs Linux. It is Intel vs non-Intel. Intel (and knock-offs) store binary data in low to high (unnatural) order, whereas IBM and Motorola chips store bytes in high to low (natural) order.

BH and BL override the native byte order.

gordon





On Mon, May 25, 2009 at 12:59 PM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
Thanks for bringing up the subject of numeric field formats. I have never really known why some people pick one over another. I read through the documentation about them and although I can follow it, I still don't understand the APPLICATION of that information. What does it mean in the real world and what types of data should be store in which formats? It used to be based on storage space. Now, that isn't so much a problem. And BECAUSE we can store so much more information now, perhaps formats that economize on SPEED are better choices, no?

All of my numeric fields are currently either PD or N.

I have never used "B" fields before, nor have I used "D", "G", "ZD", or Date fields such as DT,DL & DH. I really should acquaint myself with some of these things. My dates are all stored as either full YCMD dates in either PD fields or N fields. I see the benefit of using serial # dates instead, but I haven't converted any of my files to that format so far. I'd probably have a lot fewer mistakes of backwards dates in data files if I used serial# dates only.

-- Susan


Gabriel Bakker wrote:
V does a RTRM$ just after the field is read. Your data does not need to be converted at all. Your keys will work fine, but when you build the key in your program you need to make sure you add the proper number of spaces back in. Because you were trimming just after you read the data anyway, you probably are already adding in those spaces when you build a key in code anyway.



B fields are binary fields. They store a number. There are many different types of Numeric Storage fields. I can't say that B is any better then PD. The only difference may be speed and storage space. I know the "N" format for storing a number is very wasteful of space. It converts the number to a string and writes it down using one byte for each digit. A "B" field is just binary a B 2 says "Use two bytes to store this number" (which gives you a range of -32,767 to + 32768).



In Linux a B field stores the high byte first, and in Windows a B field stores the low byte first. (or perhaps I have this backwards). But the point is, Linux based operating systems (including Mac OS (i think)) and Windows based operating systems read and write "B" fields differently.



Think about the Chinese reading from up to down and from right to left through the pages of the book.



Therefore, if you plan on having your same BR program run on both linux and windows simultaneously, then you will need to use "BH" or "BL" fields instead of B fields. BH fields do the same thing as B fields but force BR to always store the high byte first. BL fields store the Low byte first. Its important to use BH and BL, not B in order to make it so your programs are compatible with both linux and windows.



(The reason you might do this - BR runs faster on Linux but can display better graphics under Windows. Some BR companies use Windows BR running on a Samba share when they are at the office and use their Linux version of BR over Telnet when they are working remotely. (Telnet, while regrettably text only, is still the fastest way to access your BR programs over the Internet, unless you go all the way and make a BR Web Scripting Bridge powered Interactive Web Page)



I have no idea, however, if there is any advantage to using B over using PD or any other numeric field format. I can only imagine that using "N" is probably the slowest and most wasteful of space. But beyond N, I don't see the big advantage of using one numeric field over another. Could anyone else chime in and tell us any reasons to use one type of Numeric Data Storage format over Another?

Gabriel





_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net