Using text files instaed of Memo Fields

[Dreamweaver]

I have a large Db Which contains A Couple of Memo fields which due to the amount of data being stored in the Memo fields is starting to show signs of slowing down.

One table contains 75,000, with all memo fields above 255.

I wont have a problem with adding the extra code but was wondering if there is anything that may cause me a problem or if there's any reason(s) why I shouldn't follow this path.

Many Thanks

Mick
P.S. One Option would be to create 1-1 Tables and move the memo fields into the new tables that way I would still have an easy way of serching but it would reduce the size of the main table also none of the memo fields are included in any of the querys used, the problem with speed seems to be adding data I have checked the indexs which seem OK I can't remove any indexes Otherwise it slows down searching ACT.

A copy Of the DB Is available here but it is an 11Mb Download should anybody wish to take a look at the tables structure and be able to advise on any imporvments that would be great please remember it's designed to store very large amounts of data.

http://chartheaven.9.forumer.com/index.php?showtopic=107

best wishes

mick

 

[The_Doc_Man]

Using external text files is viable but requires more things to track during a backup cycle. In fact, if you weren't backing up, ... START NOW.

The idea of using one//one tables for memo fields is OK, and if you went so far as to store the memo fields in a secondary BE, that also works. But the raw truth is that big honkin' memo fields take time to manipulate.

If you can live without the memo fields being a part of everything you do (i.e. by making them part of a separate table that you don't always use), this is not an unreasonable path.

If you were looking for approval, you've got mine. But then, I'm known to be a pragmatist, not a purist.

 

[Dreamweaver]

Using external text files is viable but requires more things to track during a backup cycle. In fact, if you weren't backing up, ... START NOW.

The idea of using one//one tables for memo fields is OK, and if you went so far as to store the memo fields in a secondary BE, that also works. But the raw truth is that big honkin' memo fields take time to manipulate.

If you can live without the memo fields being a part of everything you do (i.e. by making them part of a separate table that you don't always use), this is not an unreasonable path.

If you were looking for approval, you've got mine. But then, I'm known to be a pragmatist, not a purist.

Thanks The_Doc_Man
I'm Afraid the memo Fields Can't be done without.
I do backup Every day to a remote server I own plus to my laptop.

I'm trying to find the best way of doing this as I can now see major problems down the line I did think Of another Back-end But the current version uses 7 would there be a limit there IE 8-10 would access handle that many connections If so That's the way I would go as works for me at the min but it's worrying me with the number of Back-ends

Thanks for your help Makes me fell a lot better.

mick

 

[dcobau]

There is also the issue of size, Access will store up to 2 G of data so, eventually, you will run out of space.

Dave