|
|
Posted by John Bell on 10/16/81 11:27
Hi
It is not clear what you are trying to achieve, but creating a concanenated
field is probably not a good idea. Separate fields and a status will be alot
easier to maintain and understand.
John
"Scott Marquardt" <wasREMOVEket5@hotmail.com> wrote in message
news:1127537539.cb0c208b60e605e1a298926bee12e52f@teranews...
> What are some good strategic approaches to using freeform text fields for
> data that needs to be queried? We have a product whose tables we can't
> change, and I need to count on a "description" field for storing a value.
> Two, actually. I'm thinking of adopting this convention:
>
> InvoiceNumber@VendorAcronym
>
> There'd be a lot of vendors.
>
> Additional issue: sometimes these values would be referred to in the
> description field, and I'd need to distinguish them as referrals rather
> than as original recorded instances of the values. For that, I imagined
> either:
>
> InvoiceNumber@@VendorAcronym
>
> or
>
> InvoiceNumber&VendorAcronym
> InvoiceNumber//VendorAcronym
>
> etc. -- something like that.
>
> I'm just wondering if there's best practice for doing anything this stupid
> (hey, I'm stuck with this as our only option just now; hopefully it's only
> temporary). How to parse out whatever I end up implementing -- well, it
> needs to be tractable.
>
> Thoughts?
>
> --
>
> Scott
Navigation:
[Reply to this message]
|