Re: Memo Fields and Curruption - Is there a solution?! [was Re: Adding rows]

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Marc (mPAMpaisl_at_optusnet.com.au)
Date: 04/15/04 

Date: Thu, 15 Apr 2004 10:03:24 +1000

<snip>
> Thank you, Marc. But, having read this article, before I go down that
> path (for various reasons, it's not the one that I'd prefer to take),
> please let me do a little perception checking:
>
> Are you advising me that continuing to use the Memo fields means that
> corruption *is* inevitable *and* that the only option is to use what
> is, in effect, a Merge to a Word form .dot as the basis for all
> Invoices and Estimates? And further are you suggesting that it is not
> feasible to use a .txt file created in Notepad as a substitute to
> contain the data that would go into the Memo fields?
Hi,
Just in the interests of safe programming and not wanting to introduce more
risks than necessary, I avoid memo fields. It's not inevitable but your user
is probably not into technical stuff, so it would be better to avoid it.

I was not advocating Word over Notepad, just if you wanted word, then that's
the type of coding you'ld want.
>
> During the course of the earlier part of my learning curve, I do
> recall seeing the ability to incorporate an .xls file into an Access
> form and - if corruption via Memo fields is, in fact, inevitable and
> unavoidable by other means - I was hoping that one might avert
> disaster by applying similar principles to a .txt file.
>
> I did get as far as using a cmd button to call Notepad, where the user
> can enter the WorkDetails:

IIRC (if I recall correctly) shelling out is more expensive than opening
within the application - it depends if notepad has an exposed object model.
If I get time later, I'll do some searches for code manipulating it.

> 3. What code would I need to ensure that in rptMyInvoice, the contents
> of subrptMyWorkDetails will be the text from Inv1234.txt?
>
> Additionally, if this particular approach is in fact doable (and is
Depends on the object model being exposed - not really the other reasons)
> not prone to future corruption and/or other problems of which, in my
> naiveté, I may be unaware) is there a faster way to convert the
> contents of the WorkDetails Memo fields of the existing 50+ Invoices
> than manually copying each into Notepad and saving? (I'm fairly
> confident I can successfully handle the task of populating the new
> txtMyWorkDetails with the correct path\filenames) Or would it take
> longer to create and test the code necessary to accomplish this?!
It is probably faster to manually do this, unless you trade off that you
will need a similar utility routine in your toolbox.
>
> Thanks, again.
> hro
> --
Marc

Relevant Pages

  • Help!!!!!
    ... Tools...Folder Options in Windows Explorer (not Internet ... It might help reverse some of ... there are reasons that restore CDs were made. ... >all coming up in notepad for some reason. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Help!!!!!
    ... It might help reverse some of ... there are reasons that restore CDs were made. ... > Just make sure to BACK UP YOUR DATA *emphasis on back up ... >>all coming up in notepad for some reason. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Memo Fields and Curruption - Is there a solution?! [was Re: Adding rows]
    ... >> entering these details and automate the saving, ... corruption *is* inevitable *and* that the only option is to use what ... feasible to use a .txt file created in Notepad as a substitute to ... contain the data that would go into the Memo fields? ...
    (microsoft.public.access.gettingstarted)
  • < >.txt cannot be accessed
    ... This has happened to me but for different reasons. ... copy this file from a diskette or did you create it ... opening it in wordpad or notepad or word for windows. ...
    (microsoft.public.excel.crashesgpfs)
  • Re: Perl project update
    ... edgrsprj wrote: ... Why Notepad? ... Why not just take a filename as ... > The following is one of the most important reasons for developing this ...
    (comp.lang.perl.misc)