bb.donnay-software.com

I received a letter, Kotra quote below. All written wonderful. However, in this regard, I have questions about what restrictions 1.9 are removed in 2.0.

1. Has the 64-bit compiler?

2. Did a possibility of using organic cores of modern processors?

3. Taken whether rigid ograchenie database size to 2 GB?

4. Taken whether hard limit on the number of fields in the database a little more than 1500?

5. Established whether visual programming environment Delphi type VFP and what the prospects in this regard?

The letter itself:


Xbase++ 2.0 the business platform

You have received this email because you have subscribed to news from Alaska Software Inc. related to Xbase++ as prof.lutsenko@gmail.com
Dear Xbase++, Visual FoxPro and Clipper developer,

With Version 2.0 a bunch of outstanding new technologies have been added to the Xbase++ development platform – in addition to the hundreds of little changes in existing features. Just some examples:

Migrate existing dbf/ntx/cdx applications to the PostgreSQL without code changes
Develop Web or connected mobile applications using Xbase++
Add multi-touch support with gestures
All these new technologies have been integrated into the existing Xbase++ development platform without affecting backward compatibility. Yes, that’s true! Xbase++ 2.0 is 100% compatible with your existing Xbase++ 1.x applications. So if you want to add touch, web or SQL – just go ahead and do it! There’s no need to rewrite your existing applications.

But there’s more! In fact, there are so many non-technical but super exciting news that I want to split these into different emails to explain each in more detail. So stay tuned.

Expect an accurate “Behind the scenes” report for the following topics in the coming weeks until the Xbase++ 2.0 product launch:

Xbase++ and Continuous Delivery/Deployment
Product Portfolio changes and Prices
Xbase++ meets Visual FoxPro
Automated Updates for Xbase++
Product Activation
New Website, created with 100% Xbase++ - no more, no less!
We also have plans to restructure our newsgroups to be able to cover the 2.0 related topics in a better way. As a first step, starting today, the “public.xbase++.generic” group will be monitored by Frank++; feel free to post your Xbase++ 2.0 related questions there.

Finally for this first message, thank you very much for all your patience. I know it is not always easy to understand what’s going on at Alaska Software. Sometimes we do not seem to be communicating very clearly. However, there are two things you can always count on: first, we are a technology-driven company and second, all our decisions are centered around our primary mission: securing your investment and supporting your business model.

With kind regards,
Steffen F. Pirsig
Chief Architect & Co-Founder
Alaska Software Inc.
If you no longer wish to receive emails from Alaska Software, please send an email to operations@alaska-software.com with remove in the subject line.

© 2014 Alaska Software Inc. All rights reserved



______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.

Eugene Lutsenko wrote:However, in this regard, I have questions about what restrictions 1.9 are removed in 2.0.

1. Has the 64-bit compiler?

2. Did a possibility of using organic cores of modern processors?

3. Taken whether rigid ograchenie database size to 2 GB?

4. Taken whether hard limit on the number of fields in the database a little more than 1500?

5. Established whether visual programming environment Delphi type VFP and what the prospects in this regard?

as i know
1.) NO, still 32bit
2.) NO, still 1 CPU
3.) NO for DBF, Yes for SQL
4.) NO, split your Table and use Relation
5.) NO, only VX

to use CXP Interface you have to learn HTML, Javascript and ...

As for DBF sizes, if you use ADS, you don't have this limit on dbf and a 4GB limit on CDX size.

Cliff.

Hi, Cliff !
No, I do not use ADS. Much easier to make your database format, generally unrestricted, except for size, disk.
It functions: LC_FieldGet() and LC_FieldPut, look: http://lc.kubagro.ru/Install_Aidos-X/_AIDOS-X.doc

Hi, Auge_Ohr!
Really sorry that they did this not done?

Eugene Lutsenko wrote: Hi, Auge_Ohr!
Really sorry that they did this not done?

about 64 / 32bit see

Frank Grossheinrich
Mittwoch, 16. Juli 2014 22:31
public.xbase++.generic
Re: 2.0

no, there is no 64bit compiler/environment integrated yet.
Xbase++ 2.0 will come as 32bit version.

Hi,

I've also received the same letter.

For '• Migrate existing dbf/ntx/cdx applications to the PostgreSQL without code changes ', is there any sample that shows how this feature will work??

Such as when we say DC_AddRec(), what will happen? Will Express++/ Xbase++ will change the command to 'Insert into ....'?

I'm sorry if it seems I'm hijacking this thread, but as I receive the same letter and have a question regarding it, I thought might as well continue in this thread.

Best Regards,

Andy

Hi, Andy.

The PostGreDBE fully emulates record-based navigation on a SQL server. Since Roger also uses the standard database commands and functions in his code, everything should work pretty well. There are a few things to be done: Migrate the tables to PostGre (command-driven or using a tool from Alaska) and replace some low level functions ("FExists" instead of "File" and some others). Take the chance to move other data stored in INI, XPF or others to tables, so no file structure for the app is needed anymore (this is no must).

To be honest, the only thing I saw using this so far were the samples shown by Steffen on several DevCons. But since some guys took part of the evaluation period, there must be complex applications already migrated to PGEDBE.

Such as when we say DC_AddRec(), what will happen? Will Express++/ Xbase++ will change the command to 'Insert into ....'?

Actually, this is a function of Xbase++, not eXpress++ because eXpress++ calls dbAppend().
The answer is YES. The data driver automatically converts dbAppend() to use the right technique.
This is done with ADSDBE and will also be done with PGDBE.

Due to the fact that eXpress++ is written in 100% Xbase++ code, there should be few migration issues.

Thanks for the reply.

Anyone knows how is the performance is like?

I'm almost done migrating a DBF based app to using native SQL for their batch computation. I've cut down their batch processing time 70%-80% using Native SQL.

Will the new feature (Xbase++ 2.0 + Postgres), achieve the same performance level as native SQL? or is it still a record by record process but using a SQLesque command?

If it can't beat the native SQL performance, I might as well continue using native SQL, rather than waiting for XBase++ 2.0 to be released.

Any pointers or information would be very helpful.

Best Regards,

Andy

Andy Edward wrote:Anyone knows how is the performance is like?

it depends on your Code ...

remember pgDBE try to emulate ISAM Style so "navigation" in a SQL Table is slower than in a DBF.
pgDBE only use Postgre v8.x Command / Function so it does not know about "MOVE OVER" oder "Row_Number()" ( for DbPosition )
when use "Filter" pgDBE try to make a Query ... will work with "simple Filter" ...

using native DLL or SQLexpress++ you have to write you own (optimized) Query ... but you need to know (Postgre-) SQL Syntax