xsharp.eu

Hello,

during the Italian meeting Robert had asked for what we would like to have after the release of all promised X# features, and one request was for a DBF Client/Server.

Advantage Database Server seems to be in maintenance mode only, and I was not able to contact the ApolloDB people. Therefore it seems to be space for a new product: a DBF client/server.

In the meantime I have compiled a short wishlist for this:

• installation-free, installable with xcopy
• drop-in replacement for DBFCDX (ADS has some incompatibilities, so the applications need to be adapted)
• server based indexing
• server based filtering
• the possbility to add user defined functions to indexes, providing a X# DLL with them on the server
• a status application that shows open files and connected users, together with an API to be used in client applications
• a different license model: buy once, deploy many for 5/10 user installations, and per-installation base for larger installations

And there are some nice-to-have features, maybe for a later version:

• an SQL interface
• an ADO.NET client for other .NET languages
• crypted communication between server and client
• possibility to run without active share

Such a project needs to be funded, so to have it realized we need some sponsors and of course some ideas what would be needed and what would be nice to have.

IMHO such a product is important for at least two reasons:
- to maintain large DBF based VO applications (there are some very big out in world - impossible to migrate to SQL)
- and to have a totally maintenance free database with positional/sequential access like DBFs for small applications in peer-to-peer networks (I have many customers like that with 2-3 PCs)

Wolfgang

Wolfgang,
to add my .2 and reverse view:
I'd like a DBF replacement, which "looks" and behaves like a DBServer. If in the backend that is really a "dbf" is IMHO not really relevant.
So, one might consider building a DBServer-like Front which sits upon a Postgres backend.
Why? Because i presume this will be easier/cheaper/faster to implement, than re-invent a 100% reliable database-machine from scratch.
YMMV, of course...

Karl

Hi Karl,

of course that would be another option, but IMHO it would be too much work to implement a DBF-like behavior to a SQL database - the positional/navigational approach is too different from the SQL approach.

And I suspect many, many DBF applications rely heavily on some of these aspects.

For sure, a SQL based, but DBF compatible RDD or dataserver would help a lot on the migration. but it can never be a drop in replacement when the tables go bigger and are to large to fit in memory.

For a DBF client/server the work should not be too much because the development team can base it on the currently development RDD - so most of the database access code should be already there.

I have heard of some very large DBF applications that are nearly impossible to migrate to SQL, so I don't think this is only an issue for me.

Wolfgang

Hi Karl/Wolfgang/Everybody else,

FFF wrote: I'd like a DBF replacement, which "looks" and behaves like a DBServer. If in the backend that is really a "dbf" is IMHO not really relevant.
So, one might consider building a DBServer-like Front which sits upon a Postgres backend.

I would like to comment here to all:
What you discussed is what I call xdbServer, which I am working on when having free time.
I took it one step further, I can SQL to TXT, SDF, CSV, INI, DBF, PostgreSQL, RDBMS with it. The missing part at the moment is to DB<Command> to any of the above, but I am close....
Regards,

Hello Wolfgang,

That would all be very interesting. I already wrote earlier that I don't consider ADS in maintenance mode but more in "no mode". Forum is closed, nobody at SAP knows anything about ADS and the only relation I still seem to have with SAP is that send me spam about their products. As if I want to do business with SAP...

Apart from that I consider it impossible to both build X# and a dbf dbserver system. For us it would only be usable when it can also process SQL statements. And other ADS users do maybe require ADT support or stored procedures. So if everyone is waiting to commit until a fully ADS compatible dbf client/server is ready it may make the mission very difficult I fear. Because until then, I am forced to keep using ADS, however much I want to throw this all away.

Dick

Hi Dick,

if you already have ADS, keep it.
I don't see this as ADS replacement, but as alternative for current DBFCDX installations.

Wolfgang

Hi Dick,

that I consider it impossible to both build X# and a dbf dbserver system

The development of this product could eventually only start when all steps from the 2018 roadmap are finished. That means a working RDD, full runtime, WinForms based GUI classes, Ado.NET based SQL classes and the Xporter for the VO class libraries.
So this would be a project for 2019....

Wolfgang

HI,

Maybe you can get an idea from this link:

http://www.kresin.ru/en/letodb.html

Here's a fork version with more advance features:

https://github.com/elchs/LetoDBf


Regards,
Mario

Hi Mario,

that looks interesting - in fact it seems to be a similar thing as we would like to have in X#.

Personally I would prefer an X# solution: 64 bit, and written in .NET

Wolfgang

Hi Wolfgang,

Yes of course, an X# implementation will definitely be interesting.

Regards,
Mario