Michel
Yes, IMO your idea is good, to do partitioning on the Memo field.
I did partitioning on the tables, and one of the best methods i found is base the tables on some field, for instance the year, etc...
In conclusion, and in order to facilitate data retrieval, i would try to achieve what you propose *without* a connecting key, i.e basing the memo FPT names on fields or part of fields from the DBF. You could, for instance, base the Memo fpt name on month(AddDate), which will split your size by 12. This way you don't have to change data structures, and you suffer less to implement...

My 2 shekels

Jaime

>I have been thinking about something tonight in regards to the 2 Gig limit of Visual FoxPro. AFAIK, the limit is reached as soon as one of the related files for a table reaches the size of 2 Gig. So, if I have 4 millions records in Table.dbf for 135 Meg, with a Table.cdx for 45 Meg and Table.fpt for 1.8 Gig, it means that as soon as the first file associated with that reaches the 2 Gig limit that it won't work anymore. So, basically, the memo file is likely to reach that limit first.
>
>Assuming that is true, and please someone can validate this, the simplest thing to do to continue work as is with this table would simply be to create an additional field in Table.dbf, such as TableID of type Integer, for example, which can hold the location of the memo file associated with that record.
>
>For example, let say I have this for the first five records of Table.dbf:
>
>

>Numero       Title            AddDate             TableID
>1            My first tile    05/05/2005 11:11:11 1
>2            My second tile   05/05/2005 11:11:11 1
>3            My third tile    06/05/2005 12:11:11 2
>4            My fourth tile   06/05/2005 13:11:11 2
>5            My fifth tile    06/05/2005 14:11:11 2
>

>
>Let say I have this in TableMemo1.dbf:
>
>

>Numero       NoTable Notes
>1            1       Memo
>2            2       Memo
>

>
>And this in TableMemo2.dbf:
>
>

>Numero       NoTable Notes
>1            3       Memo
>2            4       Memo
>2            5       Memo
>

>
>Then, it would mean, I would only have to create a new TableMemoX.dbf when the limit is about to reach 2 Gig and adjust a small portion of the code to know where to get the memo when needed and where to save it at save time. Of course, I would need to transfer the memo field from Table.dbf and scale it down to TableMemoX.dbf.
>
>Is this about the simplest way to go to workaround that 2 Gig limit?
>
>Any confirmation?