I think the real solution is to re-think the underlying key. If you had a two-part key consisting of the alphabetic code and a six-digit numeric field, you could use an edit code to allow entry of the dashes while the underlying numeric value would always be returned in its correct form. Your logical would have a composite key of both fields.

Narayanan R Pillai wrote:
Wilt,

That is correct, There is only one part ( A-123-300 ). The users enter that as A-123300 or A123300 and we need to be able to match it to A-123-300.

My concern really is that building an index on replace( part, '-', '' ) might impact performance, and not building it might impact the query. D**d if I do, D**d if I don't :/

Pillai
Wilt, Charles wrote:

No,

He said there are _NOT_ any parts that different only by where/how many dashes.

The user will sometimes enter part A-123-300 as A-123300 or even A123300.

But there's only one part.

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx
Sent: Friday, August 19, 2005 1:42 PM
To: Midrange Systems Technical Discussion
Subject: Re: SQL Query Scalar Function Versus Second Table


Let me get this right.

You have two items in your item master. One is A-123300 and one is A-123-300. Now the user enters a transaction for A-12-33-00. It should strip the dashes off of A-12-33-00 and post it to the first item in the item master that (when stripped of it's dashes) matches? So we don't care about the balance of A-123-300? We can always sum up the balance for A-123300 and A-123-300 to get the total balance?

Rob Berendt





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.