Memo Fields

[alexmuir]

Hello

We are about to take on a new client whose current application is Access and yes it has a memo field.

Couple of questions.

Do memo fields actually work in Alpha V10.5
Forget all the techie theorising but are they robust enough to include within a full blown 20 user business application?

An application where users are going to be copying and pasting text into at least one core memo field.

On previous versions of Alpha we have had nightmarish corruptions with memo fields and traditionally don't use them.

I think (alas my A5 developer doesn't) that as a user I can see great benefit in having a memo field in a mission critical business application...but only if I can rely upon it.

I've read Peter Wayne's approach to including them but my old grey haired almost balding A5 man goes three shades of green and starts to shake violently when I mention including them in applications!

However, surely they must work in the current V10.5?

Secondly, are there are pointers that I should be aware of when I come to import the client's current Access data?

Any contribution would be grateful.

Many thanks

Alex

[jkletrovets]

Re: Memo Fields

Hi Alex,

Yes they do work. I follow Dr. Wayne's advice and keep all memo fields in their own table. So a typical memo table for me contains 7 fields. They are summarized below:

UID field - record unique ID field
LinkNum Field - the linking field that ties this record to its parent
Memo Field - the actual memo field
Added By - who added the record (my app tracks this)
Add Date - date and time record was added
Edited By - who last edited the record
Edit Date - date and time of last edit

Other than that I just follow Dr. Wayne's advice and create all new records programmatically first and then present it to the user in Edit Mode. I think this is key as you get the record created without the user possibly starting a new record the "normal way" using a form and then sitting in that new record state for a potentially long time. If you read Dr. Wayne's article then this is familiar.

It is quite simple once you do it. I have never had a memo corruption using this method.

One other thing I do is make all memo data entry forms modal....so the user must save and close the form to go to another area of the program. This linear in and out methodology seems to work for me with all data entry actually.

Regards,

Jeff

[Peter.Greulich]

Re: Memo Fields

... and create all new records programmatically first and then present it to the user in Edit Mode....

Jeff, I think that is what is making him shake.

[jkletrovets]

Re: Memo Fields

Hmmm.....perhaps you are right Peter.

Alex,

If you decide to move ahead in the memo direction and need help with it, I will create a sample for you based on Dr. Wayne's methods.

Just let me know.....

Regards,

Jeff

[alexmuir]

Re: Memo Fields

Jeff

Many thanks for you detailed reply and I will take you up on your kind offer.

Both the thoughtfulness of your reply and offer are a benchmark to us all.

Peter

Thank you for your input however, why do I feel having read it that I have just walked into some quicksand!

You know it would be comforting if Alpha would comment on my concern.

After all I would have thought that this an ideal opportunity where a definitive response would not only help me, but comfort the many other developers who over the years have experienced the frustrations of corrupt memo files.

Once again Jeff & Peter , many thanks for your inputs.

Alex

[Tom Cone Jr]

Re: Memo Fields

Caution. If the users are going to be pasting material from third party apps (spreadsheets, word processors, etc), you may be headed for trouble. Alpha's memo fields are expecting text, not invisible printer or formatting control codes.

[jkletrovets]

Re: Memo Fields

Hello Alex,

Attached is the sample I made for you. I tried to comment the code pretty well. More lines of commenting than actual code - so don't be frightened. :)

Things to note:

1. Open the Orders form. Notice the "Memo" button will show the text in red and tell you that no memo exists for this order. The code for this is in the form's OnActivate event. The text will change to "Memo Exists" and the color will turn green after you add a memo. I have found that the users like this functionality since they don't have to click on the button to see if there is a memo.

2. The Memo form itself is set up as Modal Dialog. This way the user must deal with the Memo and save it or cancel it and not leave it hanging open on the network. The modal part makes sure the user physically hits the "Edit" button. This prevents unintended changes that I have found invariably occur if the user is just reading the memo. :)

3. This sample just shows my preferences....yours might/probably will differ.

4. Check the OnPush event of the Memo Button to see the code and logic.


Hope this help you get going. I have several apps that use memo fields in networked environments using this methodolgy with no issues at all.....so no need to be afraid of them in my opinion.

Regards,

Jeff

[alexmuir]

Re: Memo Fields

Hi Jeff

Very kind of you and much appreciated by not only myself but also any others worried about memo fields.

Discussing this post with my A5 developer he makes the following
points

For a long time with memo fields I did indeed store them in a second table linked by e.g. jobno. The table only contained the link field and the memo field.

I either created a set based on a one-to-one relationship with the parent and a form based on the set (as per Wayne) or as a dialog box which you have to save and close before doing anything else.

I have not used modal forms.

However I wonder if this approach works safely on some of the poor quality networks we find?

There are also other issues with memo fields. Clients have told me they typed in a load of text, pressed save and lost the lot. I have done the same on my laptop.

I would value your and anyone elses comments on his remarks.

Many thanks

Alex

[alexmuir]

Re: Memo Fields

Tom

Many thanks for your input.

It raises an interesting point.

Users want to be able to cut & paste into their A5 application.

Accepting that Alpha memo fields are only for text do you have any suggestions on how this could be accomodated?

A typical example being where an employee has to visit a client and wants to copy a Google map into the clients A5 record.

Okay I know you can set up hyperlinks, but the average employee has neither the time, patience or skill to do this.

After all they can cut and paste freely with other desktop applications (Microsoft Office OneNote springs to mind) a comment that is often made is why can't I do this with the A5 database?

There are a million and one examples one could cite where the ability to cut & paste either text and/or graphics into Alpha would be really useful.

Can you do this in Access or Filemaker?

Many thanks

Alex

[Tom Cone Jr]

Re: Memo Fields

Alex, there are a variety of field types that can be used in the design of your table structures. If I were interested in accessing graphic images I'd use a JPEG field or an Image Reference Field. Maybe I'm being too conservative (stuck in a rut?) but I think memo fields are best thought of as fields that are designed for variable length text that is too long to fit in a character field. Super-sized character fields, is how I think of them.

If others are storing different data in their memo fields I'd like to hear (and learn) from them.

-- tom

[jkletrovets]

Re: Memo Fields

I either created a set based on a one-to-one relationship with the parent and a form based on the set (as per Wayne) or as a dialog box which you have to save and close before doing anything else.

Just my take.....I almost always stay away from making the memo fields as part of a set. The reason is application speed. Since the memo tables have the ability to be large....I prefer the method in my demo because then the network traffic to open the memo only occurs if the user clicks on the memo button. If the memo is part of the form set, all of that overhead occurs each time the form is loaded. Once again, just my perspective.

I have not used modal forms.

They just make sure the user actually wants to edit the record versus read what is in the memo. I think they make sense when using memo fields.

However I wonder if this approach works safely on some of the poor quality networks we find?

I guess I can't answer that. I don't find any poor quality networks. I infer poor quality to mean bad connections / infrastucture. I never see this. If poor quality were to mean 10MB networks, then I guess I would say....no Alpha app will run with the speed users have come to expect these days. Gigabit is the only way to go and cheap. As far as the "safely" concern, I can just offer that I have never had a memo corruption using the method in my demo and I have one client that I swear looks for ways to break stuff. :) Their app is a 20+ user networked app btw - which is similar to what you mention in your first post.

There are also other issues with memo fields. Clients have told me they typed in a load of text, pressed save and lost the lot. I have done the same on my laptop.

Hmmm....I have never seen this.

but I think memo fields are best thought of as fields that are designed for variable length text that is too long to fit in a character field. Super-sized character fields, is how I think of them.

I agree with Tom on this. I think of memo fields in this same exact way.


As far as capturing other data.....google maps, etc. I went this route. I have what I call reference documents. They can be anything - PDF, Excel, Word Docs. I wrote code to let the user point to the document they want to "link" to an order - they select it....then I rename the file to something like 99999-1 (where 99999 is the order number). The ref doc table keeps track of all of this and each subsequent addition for that order is 99999-2, 99999-3, etc.. In my user interface, I let the user enter a short description for what the document is. This way when you are looking at all the ref docs for an order - you can "see" what it is without opening it. If the user wants to open it, there is a button to to view document. All the button does is use Alpha's sys_open() function to open the file. I should mention I devised a directory structure so that each ref doc is stored in a directory that is the order number. Even though Alpha could open the files from anywhere, my desire to keep things neat and tidy led to make this ref doc directory structure.

Another feature of a system like this is that the users can EASILY email the document from the ref doc form as well. My users really like this feature FWIW.

Regards,

Jeff

[martinwcole]

Re: Memo Fields

Although I have used memo and rtf memo fields sparingly over the years using Alpha (since 1998) so far I have NEVER had corruption of a memo or an rtf memo.

However, using Dr, Waynes, approach, when a user enters a new parent, I silently enter a record for all related memos or rtf memos with one space - and users are never entering memos - only editing them.

I have users copy and pasting, and although they complain when they can't put pictures, excel files, etc., in a memo field like they could if they were pasting to a word document, they do it anyway. And although the copy and paste will almost never work perfectly, it works well enough that they can make minor modifications to the pasted data, and live with it.

I don't know about the future as regards doing similar with sql, but I suspect it will come around.

For the rtf memos I use and idea I got from Selwyn, and a lot of help from Tom Cone, where for every memo, I create a separate text file containing the rtf text, and if I ever have corruption, I can reconstruct the entire table.

[Raymond Lyons]

Re: Memo Fields

....For the rtf memos I use an idea I got from Selwyn, and a lot of help from Tom Cone, where for every memo, I create a separate text file containing the rtf text, and if I ever have corruption, I can reconstruct the entire table.

Martin,

Could you please elaborate on the above just a little bit. I get the general idea but I and I am sure others am/are not clear on details. For example, what links a text file to a record (file name, I presume) and how do you go about the rebuilding process if you ever have to--and have you ever had to? I also wonder if it has to be a separate text file for each for record or could it be just one text file for all....--oh no, I already see multi-user problems with that thought. Thanks.

Raymond Lyons

[Peter.Greulich]

Re: Memo Fields

As far as capturing other data.....google maps, etc. I went this route. I have what I call reference documents. They can be anything - PDF, Excel, Word Docs. I wrote code to let the user point to the document they want to "link" to an order - they select it....then I rename the file to something like 99999-1 (where 99999 is the order number). The ref doc table keeps track of all of this and each subsequent addition for that order is 99999-2, 99999-3, etc.. In my user interface, I let the user enter a short description for what the document is. This way when you are looking at all the ref docs for an order - you can "see" what it is without opening it. If the user wants to open it, there is a button to to view document. All the button does is use Alpha's sys_open() function to open the file. I should mention I devised a directory structure so that each ref doc is stored in a directory that is the order number. Even though Alpha could open the files from anywhere, my desire to keep things neat and tidy led to make this ref doc directory structure.

Now I'm shaking...;)

[Peter.Greulich]

Re: Memo Fields

I have users copy and pasting, and although they complain when they can't put pictures, excel files, etc., in a memo field like they could if they were pasting to a word document, they do it anyway.

Hey Martin,

How, exactly, do you copy a google map into a memo? I just tried and neither a memo nor RTF will acknowledge that there is anything in the clipboard.