jwcolby
jwcolby at colbyconsulting.com
Wed May 28 17:34:54 CDT 2008
>It worked very well and let the users browse the main table at normal speed without pulling the large picture field. That certainly makes sense. In this specific case the memo field is the focus of the record so it would seem to make less sense. John W. Colby www.ColbyConsulting.com Gustav Brock wrote: > Hi John > > You may be right ... perhaps behind the scene the way JET keeps the memos at separate pages is similar to keeping them in a separate table. But still - even when users are adding new records, the related memo record in the separate table is kept closed which would not be the case if the memo exists in the main table. > > The idea came from storing pictures as blobs. I kept them in a separate table in a separate mdb to not hit the 2GB size limit. The picture table only contains an ID and the picture. It worked very well and let the users browse the main table at normal speed without pulling the large picture field. > > /gustav > >>>> jwcolby at colbyconsulting.com 28-05-2008 23:45 >>> > LOL. > > You know what, I may yet use a piece of that. I am not sure > if the "separate table" is useful or not. I would be > interested in hearing how you came to use that construct. > The "partially bound" with the memo itself unbound is a > brilliant idea. Kinda "the best of both worlds". the > record lock does not take effect because of an edit to the > memo (which is the only field edited the second and > subsequent times) and the locked flag would solve the rest. > > So why the separate table for memos? > > John W. Colby > www.ColbyConsulting.com > > > Gustav Brock wrote: >> Hi John >> >> So why not try out #48 (mine)? It works and is so simple that it hurts. >> It will only lock the memo field for the split second it takes to save it. Lunch break or not. >> Add a field for a locking flag as suggested by Max and you are nearly done - still having your form bound. >> >> /gustav >> >> .. I have had about 47 posts COMPLETELY IRRELEVANT .. > > >