Many to many relation. How?

[Robert Brenstein]

>  > Also note that TIMESTAMP can be made as ULONG or ULLONG (8 byte) integer
>>  value in the format
>>
>>  YYYYMMDD  HHMMSS
>
>OK, let's see, if I got it.
>
>I take the current date and time as string and add the recid as string and
>store it into a LLong
>
>val("20041205143211"  + str(recid))
>And this is really save? Or must the recid filled up with "0" s?
>
>val("20041205143211"  + "00000000000125")
>
>sorry, may be silly, but I and math....
>
>Thanks,
>Ralf

I think you are trying to make it more complicated than needed. It is 
simpler to just use these fields separately.

The timestamp field could be in yyymmddhhmmss format as suggested by Ruslan

   20041205143211

or what the seconds function as supplied by the OS returns (a long 
integer with seconds from some arbitrary point in the past). This 
might not work, though, if your clients use different OS's since the 
reference points vary somewhat between OS's if I am not mistaken.

RecId field is maintained by Valentina and let it do it for you. You 
just need to explicitly include it in SQL queries. Like

    Select recId,* From ...

If you want the outcome ordered by the entry time:

    Select recId,* From ... Ordered by created_timestamp

if you need your serial number to have a certain fixed numeric 
length, you can create an extra field that contains recId+baseOffset 
(if you want 5 digit numbers, baseOffset would be 10000 for example).

In some of my programs (in particular when I need to collect data 
through a few web views), I create a new record using recId as the 
item identifier but leaving the "serial number" field empty until all 
data is there and approved. Only then, I copy the recId (or 
recId+baseOffset) into that field. This allows me to recycle records 
with incomplete/abandoned entries without having to do any explicit 
maintenance. Such a "serial number" field can also be used as a 
traditional primary key should a need arise.

Robert Brenstein