I DONT KNOW WHAT FOR LOCK STRATEGY IS. CAN YOU TELL ME THE DETAILS ABOUT IT.

Locking strategy is "abandoned" in DataEase 8.5.

We now only support Opportunistic Locking which is Default.

When Migrating to DataEase 8.5 the locking strategy will automatically be migrated to Opportunistic Locking or Simply DataEase Multi Access Protocol.

I did find out the hard way at the client site.

It would be nice to have some updates about these changes on the Blog. Unless it is there, still hard to find something on the blog.
Another thing I found out, RDRR*.DBM no longer there for new databases created with 8.5 ??

The reason that DataEase 8.5 is not officially released is that officially release a software involves some formalities like us putting the final stamp on it, listing the changes to both product and license so you all can make an educated decision to upgrade or not.

Until the software is officially released i.e. Beta etc, it can change at a minutes notice which is why we don't recommend for it to be used in production as one might have to rework stuff after the final release.

Obviously users want to use new features as fast as possible which is why we will signal what features we know is finished and hence ready for use, and what isn't.

At the moment you can download a full release of DE8.5 but it is not an official release as we are still finalising it but we have come to a place now where we no longer will change any functionality so for users that are prepared to take the risk of running an pre-release version of 8.5 it is available.

For instance as part of the Remote() functionality there is a full SMTP,POP3,IMAP module which is not yet published simply because it is not properly bedded in and tested. 

When it is it will simply revolutionise how DataEase deal with email as you will be able to both send/receive email directly into a DataEase database with all kinds of formatting and attachments.

In all cases it would be reasonable to expect that one will test new features and new software in house before taking it to a client site.

When it comes to changes like the one to RDRR that is simply not of public interest. This is an internal system file that users in general should not have a relationship with.

Obviously as things progress we need to make steps to make it harder to interfere with these system files rather than simpler as this opens to manipulation of applications which in the long run is not to the best for users of DataEase applications.

We are currently working with a Publishing program for DataEase applications where the entire application will be encrypted and inaccessible to any DataEase developer tools at the end point.

We are fully aware that tools to fix certain problems is missing and as such there is occasions when interfering directly with the files are necessary but the solution is not to publicly document the format but rather to publish tools that fix these problems.

However ;-)

The change to RDRR this time is not so sever but simply a necessary step to protect the user from himself.

DE8.5 is in no way backwards compatible with 8.2 or previous so when moving to 8.5 we need to insure that users don't attempt to open the applicaton in previous versions of DE8 and due to a flaw in the versioning model in DataEase we can't force them not to open a DE8.5 application without changing the name of the RDRR as well as the format and version.

DataEase 8.5 has doubled the available functionality compared with 8.2! so imagine if you tried to run a DE8.5 application in DE8.2?

Everyone is entitled to their opinion but that doesn't mean that it is of general interest. 

We have a very strict policy of not redacting information on the forum, but that is with the mutual understanding that one use it for giving or getting help to solve problem.

We can't see how you latest "contributions" fall into any of these categories and we must ask you to stay on topic.

Whatever have happened in the past cannot and will not dictate what happen in the present or the future. 

We develop DataEase as we think it is best for DataEase, current and future customers in that order. 

We are aware that many people think that DataEase should have gone down another route at varies junctions in the past but that is as it may be and nothing one can do about it now.

I will make you aware that it is a completely different team that Develop DataEase now compared to the teams that made DFW originally, the team(s) that made 5.x, 6.x and 7.x.

We are acutely aware that DQL was and is a core part of what makes DataEase special and this is why we have integrated it widely in DE85 (much more than any time before including 2.,5 and 4.x)

You might be right that DataEase for a long time was to interested in being a Microsoft Compliant and centric product, but nothing could be further from the truth in DE8.

We are moving forward and  you can be part of the journey or not. The only thing we ask is that one do it with an honest and open mind, and with good humour.

We don't get everything right, but neither did they back then and just because one doesn't agree doesn't mean one is right and the other one is wrong.

Yes, I agree.

Some people go off topic unnecessarily. 

I must admit DataEase 8.5 go beyond and above with power and functionality compare to where we were before 5 years ago.

Unfortunately pretty much all the programming out there is getting like this.
Developers are needed to get something done. In a way it is good for people doing business.

Business owners should not try to do programming and run their business at the same time.
If they did, they will never move forward. They might save some money in the short period.

I am happy as a partner, this product is growing into a beast, even I am thinking partners needs training directly from DataEase.