In DataEase 7 the old Memo was replaced with the new memo.

As much as the intentions and the idea was good, it was a catastrophic decision, especially as the implementation was shoddy as so much of the new functionality in DE7.

The old development team/management was strong believers in migration and changing functionality. As we have seen the catastrophic consequences of this we are strong believers of the opposite approach. "If it works, don't change it." and "Expand and add new functionality, but never remove or change!"

The problem with the change from old to new memo was the way the memo is stored. Where the old memo (maximum size of 4000) is saved as up to 16 fields of 255 characters each, the new memo is saved in a separate file where each field can contain a maximum of 64k.

So far so good and if Memos was just used for exactly that....being a Memo (notpad) then it would have not been a problem, but in DFW 5.x and 6.x it was mostly used as a slightly larger text field (500/1000 characters) rather than as a memo i.e. LongText.

Since old Memo is part of the DBM file, they are as fast and agile as any other DataEase datatype, but not so with new Memo. When designed they were designed as just being a memo and not for programming/searching or any kind of dynamics.

So when migrating a DFW 5.x/6.x app to DFW 7 you basically "kill" the speed and cause a lot of problems if the old memos get migrated to new memos.

This and a lot of other problems like Forms GPFing if you have used buttons without actions (very popular in 5.x and 6.x to create inverted boxes), OML GPFing after migrating, lack of Menu documents and erroneous migration of menus to Forms, most 5.x/6.x users has not migrated their apps forward.

DataEase 8.1 is all about catching up with the past. We have now "re-introduced" the old style Memo which in reality was a LongText field and the way we have done it is as follows.

We have simply expanded the normal text field to 4080 characters.

But due to the limitations of the DataEase database we need to do it the same way as the old memo i.e. span up to 16 text fields of 255 characters.

There is benefits to this though as you can reference each element of the LongText field by its element name which would be FieldName+Number. So if fieldname is MyTextField and it is 4080 long, you would have 16 fields called from MyTextField1 to MyTextField16.

They will be invisible, but if you reference them in DQL/Derivation it will work.

Working with Memo and old style Memo has it's limitation. For instance can you not search in any of them outside the first 255 characters (i.e. first field in the list).

This limitation has been removed in LongText so you will now be able to search an entire longtext field a feature that will be very useful.

The transition between Normal text field and longtext is also seamless, and longtext fields can also be virtual.

We are currently looking into extending string functions to work with the full longtext as it would be useful to be able to manipulate the entire object as one.

Next step on the path to "compatibility" with earlier versions of DFW is Menus.