Concatinating numbers

[Elias.]

Hi Karen,

In the past, I have used the ObjectPtr fields to get all 'children' of 
a given node, then checked to see if any of them have the properties I 
need, rather than building identifiers...it sounded like that may also 
work in your case...As I said, I didn't have your original post to make 
my description fit your exact use...sorry if I have the wrong end of 
the stick :-)


On 26/05/2004, at 11:58 AM, Karen wrote:

>
> On May 25, 2004, at 11:04 PM, Elias. wrote:
>
>> Can you do this using a structure something like:
>>
>> Table	Field
>> Vial		Label -- human readable Vial Identifier
>>
>> Sample	VialPtr -- Pointer to Vial
>>
>> Run		SamplePtr -- Pointer to Sample
>>
>>
>
> Why have a separate table for vials when you have one for Lot,
> and vials only matter when used samples for a specific run?

> So what do you see (if any) is the advantage of a separate vial table 
> in this case?
>
> But what you propose is similar in concept to a LIMS (Laboratory 
> Information Management System for those that are unfamiliar)  I once 
> worked with. In part they used:

Many years ago, I designed one of those :-)
>
> In my current situation, I'm only worried about one Analysis (type of 
> test) and current lab practice is not to assign an absolutely *unique* 
> human Identifiable ID to each vial... So I would have to get the lab 
> to agree to create and maintain a system to assign one... And I'm not 
> writing a full blown LIMS!

If you only have one test (stress testing concrete cubes, let us say) 
then you never need to identify the TYPE of the test, but each tested 
cube would still need an ID (what your calculated field is doing, I 
think)...so if you get 3 cubes from one pour, that would be the 
equivalent of 3 samples from one vial (does that sound correct ?)

> The Vial ID's currently used are unique for the lot *only* within that 
> Run, and used just to group results by vial to get am estimate of vial 
> to vial variability for the lot.

Okay, so the Vial ID may be recycled...I see why you might go the way 
you have...

> Using your terminology my current Table Structure is:
>
> Lot Table : Info about lot
> Run Table: Info about that specific  test instance
>
> Sample Table : Unique combo of Run, Lot sample and a relative to the 
> run serial Vial ID
> Sample Table Fields (in part) :
> LotPtr <<-- Lot.RecID
> RunPtr <<-- Lot.RecID
> RunRelativeLotVialNumber : VByte
> etc...
>
> And the combination of LotPtr, RunPtr, and RunRelativeLotVialNumber  
> define a unique Identifier for a vial for calculation purposes



Elias.

You only have the rights you defend in others.