Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Recommendation please regarding indexed column

9 posts in General Discussion Last posting was on 2003-09-09 15:19:12.0Z
Darrell Guard Posted on 2003-09-08 20:31:31.0Z
From: "Darrell Guard" <dguard_nospam@gianttiger.com>
Newsgroups: ianywhere.public.general
Subject: Recommendation please regarding indexed column
Lines: 19
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: host11.gianttiger.net
X-Original-NNTP-Posting-Host: host11.gianttiger.net
Message-ID: <3f5ce723$1@forums-1-dub>
Date: 8 Sep 2003 13:31:31 -0700
X-Trace: forums-1-dub 1063053091 209.226.65.11 (8 Sep 2003 13:31:31 -0700)
X-Original-Trace: 8 Sep 2003 13:31:31 -0700, host11.gianttiger.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1718
Article PK: 3939

Hello,

We have a need to store barcode values of up to 18 digits in our database as
a primary key. The current requirements want these barcode values to be
stored as 18 digit character values. Leading zeroes are always be used to
pad barcodes less than 18 digits.

Has anyone seen issues, such as corruption and/or page faults, when defining
an index (unique/primary or non-unique) against a lengthy character column
in a table that consists of over 150K records.

Comments about whether defining this barcode column should be defined
numeric(18,0) versus char(18) are also appreciated.

Thank you.

Darrell


Breck Carter [TeamSybase] Posted on 2003-09-09 11:14:20.0Z
From: "Breck Carter [TeamSybase]" <NOSPAM__bcarter@risingroad.com>
Newsgroups: ianywhere.public.general
Subject: Re: Recommendation please regarding indexed column
Organization: RisingRoad Professional Services
Reply-To: NOSPAM__bcarter@risingroad.com
Message-ID: <b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com>
References: <3f5ce723$1@forums-1-dub>
X-Newsreader: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: bcarter.sentex.ca
X-Original-NNTP-Posting-Host: bcarter.sentex.ca
Date: 9 Sep 2003 04:14:20 -0700
X-Trace: forums-1-dub 1063106060 64.7.134.118 (9 Sep 2003 04:14:20 -0700)
X-Original-Trace: 9 Sep 2003 04:14:20 -0700, bcarter.sentex.ca
Lines: 38
X-Authenticated-User: TeamPS
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1720
Article PK: 3942

AFAIK the length of an index column has nothing to do with the
likelihood of corruption.

The length does affect performance, but it depends *greatly* on what
version of ASA you are using, so further discussion must wait :)...
the leading zeros may or may not be a huge deal.

Also, the type of queries most commonly used is important to know.

Highly recommended: The Version 9 Index Consultant.

Breck

On 8 Sep 2003 13:31:31 -0700, "Darrell Guard"

<dguard_nospam@gianttiger.com> wrote:

>Hello,
>
>We have a need to store barcode values of up to 18 digits in our database as
>a primary key. The current requirements want these barcode values to be
>stored as 18 digit character values. Leading zeroes are always be used to
>pad barcodes less than 18 digits.
>
>Has anyone seen issues, such as corruption and/or page faults, when defining
>an index (unique/primary or non-unique) against a lengthy character column
>in a table that consists of over 150K records.
>
>Comments about whether defining this barcode column should be defined
>numeric(18,0) versus char(18) are also appreciated.
>
>Thank you.
>
>Darrell
>

bcarter@risingroad.com
Mobile and Distributed Enterprise Database Applications
www.risingroad.com


Darrell Guard Posted on 2003-09-09 12:29:15.0Z
From: "Darrell Guard" <dguard_nospam@gianttiger.com>
Newsgroups: ianywhere.public.general
References: <3f5ce723$1@forums-1-dub> <b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com>
Subject: Re: Recommendation please regarding indexed column
Lines: 64
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: host11.gianttiger.net
X-Original-NNTP-Posting-Host: host11.gianttiger.net
Message-ID: <3f5dc79b$1@forums-1-dub>
Date: 9 Sep 2003 05:29:15 -0700
X-Trace: forums-1-dub 1063110555 209.226.65.11 (9 Sep 2003 05:29:15 -0700)
X-Original-Trace: 9 Sep 2003 05:29:15 -0700, host11.gianttiger.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1721
Article PK: 3941

Thanks Breck,

We will be using ASA 8.02. The number of deletes will be typically low
because this will be a lookup table with not too much updating.

The reason I ask this question is because of experience with another
database product that did have 'problems' (memory leaks, bad pointers and
general corruption) when indexing character data. It is important for me to
know that the database is stable with this type of key. My own test, which
I let run overnight, reveal no issues (random writes and deletes every 1/10
of second (so far) resulting in almost 900,000 rows being manipulated.

Lastly, I am not familiar with the reference "The Version 9 Index
Consultant". Can you point me in the right direction?

Darrell

"Breck Carter [TeamSybase]" <NOSPAM__bcarter@risingroad.com> wrote in
message news:b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com...
> AFAIK the length of an index column has nothing to do with the
> likelihood of corruption.
>
> The length does affect performance, but it depends *greatly* on what
> version of ASA you are using, so further discussion must wait :)...
> the leading zeros may or may not be a huge deal.
>
> Also, the type of queries most commonly used is important to know.
>
> Highly recommended: The Version 9 Index Consultant.
>
> Breck
>
> On 8 Sep 2003 13:31:31 -0700, "Darrell Guard"
> <dguard_nospam@gianttiger.com> wrote:
>
> >Hello,
> >
> >We have a need to store barcode values of up to 18 digits in our database
as
> >a primary key. The current requirements want these barcode values to be
> >stored as 18 digit character values. Leading zeroes are always be used
to
> >pad barcodes less than 18 digits.
> >
> >Has anyone seen issues, such as corruption and/or page faults, when
defining
> >an index (unique/primary or non-unique) against a lengthy character
column
> >in a table that consists of over 150K records.
> >
> >Comments about whether defining this barcode column should be defined
> >numeric(18,0) versus char(18) are also appreciated.
> >
> >Thank you.
> >
> >Darrell
> >
>
> bcarter@risingroad.com
> Mobile and Distributed Enterprise Database Applications
> www.risingroad.com


Paul Horan[TeamSybase] Posted on 2003-09-09 13:03:22.0Z
From: "Paul Horan[TeamSybase]" <paulhATvcisolutionsDOTcom>
Newsgroups: ianywhere.public.general
References: <3f5ce723$1@forums-1-dub> <b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com> <3f5dc79b$1@forums-1-dub>
Subject: Re: Recommendation please regarding indexed column
Lines: 27
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: ny-chicagost2d-63.buf.adelphia.net
X-Original-NNTP-Posting-Host: ny-chicagost2d-63.buf.adelphia.net
Message-ID: <3f5dcf9a@forums-1-dub>
Date: 9 Sep 2003 06:03:22 -0700
X-Trace: forums-1-dub 1063112602 24.49.119.63 (9 Sep 2003 06:03:22 -0700)
X-Original-Trace: 9 Sep 2003 06:03:22 -0700, ny-chicagost2d-63.buf.adelphia.net
X-Authenticated-User: TeamPS
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1722
Article PK: 3943


"Darrell Guard" <dguard_nospam@gianttiger.com> wrote in message news:3f5dc79b$1@forums-1-dub...
> Thanks Breck,
>
<snip>
>
> Lastly, I am not familiar with the reference "The Version 9 Index
> Consultant". Can you point me in the right direction?
>
> Darrell
>

The Index Consultant is a new "wizard" feature that ships with ASA9. It analyzes typical usage patterns against the
database and can recommend new indexes, or to drop existing unnecessary indexes.

--
Paul Horan[TeamSybase]

Get the new PB9 books!
http://www.pb9books.com?source=newsgroups

Code samples on Sybase CodeXchange:
http://codexchange.sybase.com

ISUG Enhancement Requests:
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement


Darrell Guard Posted on 2003-09-09 14:12:57.0Z
From: "Darrell Guard" <dguard_nospam@gianttiger.com>
Newsgroups: ianywhere.public.general
References: <3f5ce723$1@forums-1-dub> <b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com> <3f5dc79b$1@forums-1-dub> <3f5dcf9a@forums-1-dub>
Subject: Re: Recommendation please regarding indexed column
Lines: 42
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: host11.gianttiger.net
X-Original-NNTP-Posting-Host: host11.gianttiger.net
Message-ID: <3f5ddfe9$1@forums-1-dub>
Date: 9 Sep 2003 07:12:57 -0700
X-Trace: forums-1-dub 1063116777 209.226.65.11 (9 Sep 2003 07:12:57 -0700)
X-Original-Trace: 9 Sep 2003 07:12:57 -0700, host11.gianttiger.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1724
Article PK: 3945

Thanks Paul,

I have forwarded this point to our development team for consideration. We
are still (just starting) to use 8.02. We will have to look at version 9 at
some point.

Darrell

"Paul Horan[TeamSybase]" <paulhATvcisolutionsDOTcom> wrote in message
news:3f5dcf9a@forums-1-dub...
> "Darrell Guard" <dguard_nospam@gianttiger.com> wrote in message
news:3f5dc79b$1@forums-1-dub...
> > Thanks Breck,
> >
> <snip>
> >
> > Lastly, I am not familiar with the reference "The Version 9 Index
> > Consultant". Can you point me in the right direction?
> >
> > Darrell
> >
>
> The Index Consultant is a new "wizard" feature that ships with ASA9. It
analyzes typical usage patterns against the
> database and can recommend new indexes, or to drop existing unnecessary
indexes.
>
> --
> Paul Horan[TeamSybase]
>
> Get the new PB9 books!
> http://www.pb9books.com?source=newsgroups
>
> Code samples on Sybase CodeXchange:
> http://codexchange.sybase.com
>
> ISUG Enhancement Requests:
> http://www.isug.com/cgi-bin/ISUG2/submit_enhancement
>
>


Breck Carter [TeamSybase] Posted on 2003-09-09 15:03:33.0Z
From: "Breck Carter [TeamSybase]" <NOSPAM__bcarter@risingroad.com>
Newsgroups: ianywhere.public.general
Subject: Re: Recommendation please regarding indexed column
Organization: RisingRoad Professional Services
Reply-To: NOSPAM__bcarter@risingroad.com
Message-ID: <pkqrlvksbgt7jbuh0jmu12bspnnqrlb29u@4ax.com>
References: <3f5ce723$1@forums-1-dub> <b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com> <3f5dc79b$1@forums-1-dub>
X-Newsreader: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: bcarter.sentex.ca
X-Original-NNTP-Posting-Host: bcarter.sentex.ca
Date: 9 Sep 2003 08:03:33 -0700
X-Trace: forums-1-dub 1063119813 64.7.134.118 (9 Sep 2003 08:03:33 -0700)
X-Original-Trace: 9 Sep 2003 08:03:33 -0700, bcarter.sentex.ca
Lines: 99
X-Authenticated-User: TeamPS
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1726
Article PK: 3947

Version 8 introduced a new index type to deal with wide index columns
so it might not matter much what data type you use, or whether there
are leading zeros.

=====
What's New in SQL Anywhere Studio
4. What's New in Version 8.0
New features in version 8
Adaptive Server Anywhere new features
Query processing and database performance
...
New index type A new type of index has been added that improves
performance for multiple column indexes and for indexes that include
wide columns. It is a compressed B-tree index.

Adaptive Server Anywhere automatically creates the appropriate type of
index based on index width (the sum of the width of all columns in the
index). A compressed B-tree index is created when the width of the
index is greater than nine bytes and less than one-eighth of the page
size to a maximum of 256 bytes; otherwise, Adaptive Server Anywhere
creates hash B-tree indexes.
=====

Have you looked at your query plans with the graphical plan facility
in ISQL? Very cool, available in 8 as well.

Breck


On 9 Sep 2003 05:29:15 -0700, "Darrell Guard"

<dguard_nospam@gianttiger.com> wrote:

>Thanks Breck,
>
>We will be using ASA 8.02. The number of deletes will be typically low
>because this will be a lookup table with not too much updating.
>
>The reason I ask this question is because of experience with another
>database product that did have 'problems' (memory leaks, bad pointers and
>general corruption) when indexing character data. It is important for me to
>know that the database is stable with this type of key. My own test, which
>I let run overnight, reveal no issues (random writes and deletes every 1/10
>of second (so far) resulting in almost 900,000 rows being manipulated.
>
>Lastly, I am not familiar with the reference "The Version 9 Index
>Consultant". Can you point me in the right direction?
>
>Darrell
>
>
>"Breck Carter [TeamSybase]" <NOSPAM__bcarter@risingroad.com> wrote in
>message news:b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com...
>> AFAIK the length of an index column has nothing to do with the
>> likelihood of corruption.
>>
>> The length does affect performance, but it depends *greatly* on what
>> version of ASA you are using, so further discussion must wait :)...
>> the leading zeros may or may not be a huge deal.
>>
>> Also, the type of queries most commonly used is important to know.
>>
>> Highly recommended: The Version 9 Index Consultant.
>>
>> Breck
>>
>> On 8 Sep 2003 13:31:31 -0700, "Darrell Guard"
>> <dguard_nospam@gianttiger.com> wrote:
>>
>> >Hello,
>> >
>> >We have a need to store barcode values of up to 18 digits in our database
>as
>> >a primary key. The current requirements want these barcode values to be
>> >stored as 18 digit character values. Leading zeroes are always be used
>to
>> >pad barcodes less than 18 digits.
>> >
>> >Has anyone seen issues, such as corruption and/or page faults, when
>defining
>> >an index (unique/primary or non-unique) against a lengthy character
>column
>> >in a table that consists of over 150K records.
>> >
>> >Comments about whether defining this barcode column should be defined
>> >numeric(18,0) versus char(18) are also appreciated.
>> >
>> >Thank you.
>> >
>> >Darrell
>> >
>>
>> bcarter@risingroad.com
>> Mobile and Distributed Enterprise Database Applications
>> www.risingroad.com
>

bcarter@risingroad.com
Mobile and Distributed Enterprise Database Applications
www.risingroad.com


Darrell Guard Posted on 2003-09-09 15:19:12.0Z
From: "Darrell Guard" <dguard_nospam@gianttiger.com>
Newsgroups: ianywhere.public.general
References: <3f5ce723$1@forums-1-dub> <b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com> <3f5dc79b$1@forums-1-dub> <pkqrlvksbgt7jbuh0jmu12bspnnqrlb29u@4ax.com>
Subject: Re: Recommendation please regarding indexed column
Lines: 130
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: host11.gianttiger.net
X-Original-NNTP-Posting-Host: host11.gianttiger.net
Message-ID: <3f5def70$1@forums-1-dub>
Date: 9 Sep 2003 08:19:12 -0700
X-Trace: forums-1-dub 1063120752 209.226.65.11 (9 Sep 2003 08:19:12 -0700)
X-Original-Trace: 9 Sep 2003 08:19:12 -0700, host11.gianttiger.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1727
Article PK: 3948

Hi Breck,

The compressed (or modified) B-Tree is available on several platforms
including the AS/400. Very nice technique to obtain optimizer statistics!
The compression logic normally divides a key into repeating (parent) less
repeating (child) halves. The string manipulation to do that needs to be
bang-on or else memory allocation errors (GPFs, Dr. Watsons) can crop up.
According to the test I performed, ASA 8.02 handled the scenario
beautifully. My test scenario included generating values with many common
leading character strings in an attempt to create as many parent to child
tree relationships as well as to hopefully skew the tree. After 1M+
database inserts and deletes resulting in over 890K records, the database
was in very good shape.

So, as it stands, there appear to be no technical reasons why the data
cannot be stored in the way that is asked of me.

Thanks,

Darrell

"Breck Carter [TeamSybase]" <NOSPAM__bcarter@risingroad.com> wrote in
message news:pkqrlvksbgt7jbuh0jmu12bspnnqrlb29u@4ax.com...
> Version 8 introduced a new index type to deal with wide index columns
> so it might not matter much what data type you use, or whether there
> are leading zeros.
>
> =====
> What's New in SQL Anywhere Studio
> 4. What's New in Version 8.0
> New features in version 8
> Adaptive Server Anywhere new features
> Query processing and database performance
> ...
> New index type A new type of index has been added that improves
> performance for multiple column indexes and for indexes that include
> wide columns. It is a compressed B-tree index.
>
> Adaptive Server Anywhere automatically creates the appropriate type of
> index based on index width (the sum of the width of all columns in the
> index). A compressed B-tree index is created when the width of the
> index is greater than nine bytes and less than one-eighth of the page
> size to a maximum of 256 bytes; otherwise, Adaptive Server Anywhere
> creates hash B-tree indexes.
> =====
>
> Have you looked at your query plans with the graphical plan facility
> in ISQL? Very cool, available in 8 as well.
>
> Breck
>
>
> On 9 Sep 2003 05:29:15 -0700, "Darrell Guard"
> <dguard_nospam@gianttiger.com> wrote:
>
> >Thanks Breck,
> >
> >We will be using ASA 8.02. The number of deletes will be typically low
> >because this will be a lookup table with not too much updating.
> >
> >The reason I ask this question is because of experience with another
> >database product that did have 'problems' (memory leaks, bad pointers and
> >general corruption) when indexing character data. It is important for me
to
> >know that the database is stable with this type of key. My own test,
which
> >I let run overnight, reveal no issues (random writes and deletes every
1/10
> >of second (so far) resulting in almost 900,000 rows being manipulated.
> >
> >Lastly, I am not familiar with the reference "The Version 9 Index
> >Consultant". Can you point me in the right direction?
> >
> >Darrell
> >
> >
> >"Breck Carter [TeamSybase]" <NOSPAM__bcarter@risingroad.com> wrote in
> >message news:b3drlvc15nnerhrfdgt85406pis24a1sco@4ax.com...
> >> AFAIK the length of an index column has nothing to do with the
> >> likelihood of corruption.
> >>
> >> The length does affect performance, but it depends *greatly* on what
> >> version of ASA you are using, so further discussion must wait :)...
> >> the leading zeros may or may not be a huge deal.
> >>
> >> Also, the type of queries most commonly used is important to know.
> >>
> >> Highly recommended: The Version 9 Index Consultant.
> >>
> >> Breck
> >>
> >> On 8 Sep 2003 13:31:31 -0700, "Darrell Guard"
> >> <dguard_nospam@gianttiger.com> wrote:
> >>
> >> >Hello,
> >> >
> >> >We have a need to store barcode values of up to 18 digits in our
database
> >as
> >> >a primary key. The current requirements want these barcode values to
be
> >> >stored as 18 digit character values. Leading zeroes are always be
used
> >to
> >> >pad barcodes less than 18 digits.
> >> >
> >> >Has anyone seen issues, such as corruption and/or page faults, when
> >defining
> >> >an index (unique/primary or non-unique) against a lengthy character
> >column
> >> >in a table that consists of over 150K records.
> >> >
> >> >Comments about whether defining this barcode column should be defined
> >> >numeric(18,0) versus char(18) are also appreciated.
> >> >
> >> >Thank you.
> >> >
> >> >Darrell
> >> >
> >>
> >> bcarter@risingroad.com
> >> Mobile and Distributed Enterprise Database Applications
> >> www.risingroad.com
> >
>
> bcarter@risingroad.com
> Mobile and Distributed Enterprise Database Applications
> www.risingroad.com


"Bruce Hay" Posted on 2003-09-09 13:24:42.0Z
From: "Bruce Hay" <hay at sybase dot com>
Newsgroups: ianywhere.public.general
References: <3f5ce723$1@forums-1-dub>
Subject: Re: Recommendation please regarding indexed column
Lines: 33
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Original-NNTP-Posting-Host: hay-xp.sybase.com
Message-ID: <3f5dd4fb$1@forums-2-dub>
X-Original-Trace: 9 Sep 2003 06:26:19 -0700, hay-xp.sybase.com
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 9 Sep 2003 06:21:59 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 9 Sep 2003 06:24:42 -0700
X-Trace: forums-1-dub 1063113882 10.22.108.75 (9 Sep 2003 06:24:42 -0700)
X-Original-Trace: 9 Sep 2003 06:24:42 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1723
Article PK: 3944

If you are not going to store the values as CHAR, you would be better to use
UNSIGNED BIGINT rather than NUMERIC. Zero-padding for presentation in your
app can be done using ASA builtin functions in the queries which reference
the table, or in a view.

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

"Darrell Guard" <dguard_nospam@gianttiger.com> wrote in message
news:3f5ce723$1@forums-1-dub...
> Hello,
>
> We have a need to store barcode values of up to 18 digits in our database
as
> a primary key. The current requirements want these barcode values to be
> stored as 18 digit character values. Leading zeroes are always be used to
> pad barcodes less than 18 digits.
>
> Has anyone seen issues, such as corruption and/or page faults, when
defining
> an index (unique/primary or non-unique) against a lengthy character column
> in a table that consists of over 150K records.
>
> Comments about whether defining this barcode column should be defined
> numeric(18,0) versus char(18) are also appreciated.
>
> Thank you.
>
> Darrell
>
>


Darrell Guard Posted on 2003-09-09 14:30:26.0Z
From: "Darrell Guard" <dguard_nospam@gianttiger.com>
Newsgroups: ianywhere.public.general
References: <3f5ce723$1@forums-1-dub> <3f5dd4fb$1@forums-2-dub>
Subject: Re: Recommendation please regarding indexed column
Lines: 49
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: host11.gianttiger.net
X-Original-NNTP-Posting-Host: host11.gianttiger.net
Message-ID: <3f5de402$1@forums-1-dub>
Date: 9 Sep 2003 07:30:26 -0700
X-Trace: forums-1-dub 1063117826 209.226.65.11 (9 Sep 2003 07:30:26 -0700)
X-Original-Trace: 9 Sep 2003 07:30:26 -0700, host11.gianttiger.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1725
Article PK: 3946

Hi Bruce,

Unfortunately, the format of the data (even how it is stored in the
database) is not up me unless I can prove that there is an issue. I agree
with you but it is not my choice.

Darrell

"Bruce Hay" <hay at sybase dot com> wrote in message
news:3f5dd4fb$1@forums-2-dub...
> If you are not going to store the values as CHAR, you would be better to
use
> UNSIGNED BIGINT rather than NUMERIC. Zero-padding for presentation in your
> app can be done using ASA builtin functions in the queries which reference
> the table, or in a view.
>
> Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
> Developer Community at http://www.ianywhere.com/developer
>
> "Darrell Guard" <dguard_nospam@gianttiger.com> wrote in message
> news:3f5ce723$1@forums-1-dub...
> > Hello,
> >
> > We have a need to store barcode values of up to 18 digits in our
database
> as
> > a primary key. The current requirements want these barcode values to be
> > stored as 18 digit character values. Leading zeroes are always be used
to
> > pad barcodes less than 18 digits.
> >
> > Has anyone seen issues, such as corruption and/or page faults, when
> defining
> > an index (unique/primary or non-unique) against a lengthy character
column
> > in a table that consists of over 150K records.
> >
> > Comments about whether defining this barcode column should be defined
> > numeric(18,0) versus char(18) are also appreciated.
> >
> > Thank you.
> >
> > Darrell
> >
> >
>
>