FiveTech Support Forums

Antonio,
Thanks for the input. I'll have to study up on that.

A couple of years ago I thought I would see what would happen if I went to an SQL database. So I took my current files and converted them into tables in an SQL database. I found that the total size was over 6 times the space used by my DBF files. Then when I started adding data, the bloat was larger.

I don't know if this was a fluke or others see the same behavior.

With all of that said, probably some day I will be using SQL files ...

Shuming

ShumingWang wrote:
In multi users envirenment(include Novell,Windows,samba server) and open many dbf tables ,dbf tables opening/shareing by many users, if comeone power off his computer or windows hang, the cdx/ntx/dbf often damaged .

My experience is very different of yours.
MySQL gets corrupted on power outages too, in the same way dbf files. I have been working with LAMP, and because a power source failure the CPU rebooted itself and the mysql daemon didn't started because an unrecoverable error given in the user database. So mysql does not warranties incorruptable data. And, as Rimantas said, in server with an UPS there are no corruption with NTX NOR CDX. A client has tables with more than 14 years of historical data online in a samba server, and *never* got corrupted.

Regards,

Carlos.

Hi everyone.

Every time I read threads about SQL vs. DBF, I purse my lips! I gave up some time ago trying to make people understand. Why would you give up DBF sequential access over SQL? (DON'T STOP READING HERE) There are some advantages to using SQL, yes --granted. There are many other advantages to using ISAM, don’t think I need to list them. I'm not even going to compare them. The comparison between SQL and ISAM is NOT the point. My question is; why abandon ISAM over SQL when you can have BOTH AT THE SAME TIME!!!!! with the very same DBFs.

The only possible explanation I can find for people (most people in this distinguished forum) to be holding this discussion is because they simply don't understand ADS (IGNORANCE). That's all. With ADS in LOCAL mode (FREE - FREE -FREE) and with the use of a Data Dictionary you may interface with the database via SQL commands if it so pleases you. Or you may combine ISAM commands with SQL or keep using ISAM and never use SQL. Look, try it. Go ahead. Compile your software to use ADSNTX or ADSCDX or Both. Keep using it as it is. Then, learn how to create and use a DD. Once you connect to a DD (even in local mode), start using some SQL commands for some new functionality.

INSERT INTO ...
SELECT * FROM ctable ....
EXECUTE STORED PROCEDURE....

With time, you'll understand why it would be stupid to abandon DBF over SQL when you can have BOTH! There are things you can do with ISAM that you just can't do with SQLs. If you sell to a small customer, you install the LOCAL (free) server. If the customer is big, then you sell the ADS SERVER. You don't change a line of code anywhere. If your small customer becomes big, then you sell them the ADS server. It's that simple.

ADS is the only database engine, that I know of, that can actually handle ISAM as well as SQL navigation of a table. People in the SQL world don't have an idea what they are missing by not having ISAM. We are very fortunate. I can almost say that we have an unfair advantage with ISAM. But I'm sure no one here will see my point. No one will understand what they are missing. People will continue to debate if SQL is the future and if DBF/ISAM should be abandoned... Life will go on as usual. And the best opportunity will pass us by without even noticing it.

What a pity....

With my best intention to wake people up and asking to be excused if I have offended you,

Reinaldo

James,

>I read this twice and I still don't quite understand it. I'm not sure if the app EXE is actually loading the server as a separate process or if it is actually inside the same EXE.

The exe would be loading it as a separate process by using provided dll's.

>One downside is that it did mention that this is only for single-user applications.

Hmm..yes it does. It would be suitable for creating demo apps though and the full server suit is only a few MBs in size to download. I'll just put this in my to-do list for later.

I can't resist having my little say on this "hot" topic.

We are kind of mixing multiple issues here. SQL itself is only a query language, originally developed for ad hoc reporting I believe and is not directly related to data integrity, rollback rollforward, transaction control etc.

Having said that most of the commonly available data base systems with these kinds of features use SQL as their query language but this is more an historical and marketing accident than anything else.

Efficient ISAM code should be significantly more efficient than SQL code in principle but the following applies:

Aside from products like ADS if you are using ISAM files you are doing individual queries and if these have to traverse a relatively slow data pipe that is not client-server then your performance will be poor vis-a-vis a good query languauge (SQL) client-server architecture.

Also many client-server products have features such as server side triggers and (often pre-compiled) stored procedures.

xBase files don't support variable field lengths which many client-server solutions do which can be space inefficient but then again so can client-server engines depending upon page sizes etc.

In my opinion SQL is ugly from an OO perspective because it is efficient only if you "bundle up" queries rather than a more atomic approach which is native to ISAM. The way forward in my opinion is OO databases.

It would be nice to write an xBase client server back end stub and spilt our code between client and server all in the language we love. That could be very efficient. Mine would have to run on Linux.

Nice thought but as I need speed for my users operating across an internet based VPN sooner rather than later I will probably just have to use SQL and something like Postgre.

Happy coding to all
xProgrammer.

xProgrammer;

With ADS you have server side triggers, Stored Procedures, transactions (with rollback and commit...), replication, variable length fields. ADS server runs on Linux, Windows, and Novell servers and it is a true client-server SQL. But you get to keep ISAM navegation. ... you get to connect to your data using the very same application via internet and/or you can write PHP/JAVA code to access your very same DBF data (this is as long as you are using a DD). So you can mix .exe with php with java, perl, .net to access the data via internet or still use your .exes.

I know, I sound like an ADS salesman. It's just that the more I learn how to use ADS, the more I love it. I got to keep the very same and OLD dbf-ntx, dbf-cdx, and have now started to use adt-adi all encapsulated on a DD using rollback transactions, stored procedures, n-way replication, server side triggers, absolute ZERO corruption, very fast access to data, SQL speed of queries,... by using ADS.

Reinaldo.

Hi Reinaldo

ADS may be my easiest solution. I've sent them an email and filled in an evaluation request. Not sure what client software I need and how to get going but hopefully they can send some info.

Regards
xProgrammer

To All

I guess I am rather unique here in that I represent State ( us government ).

I grew up on xBase and the dBase dialect and have grown to and appreciate the language as well.

In a large environment ( over 5k ) users .. I have both back ends in place ADS and MS Sql server. I can truthfully say ADS is as fast or faster than Sql server and even the US Govenrment CDC ( centers for disease control ) uses ADS as we have one of their applications running for STD*MIS.

If you go out and look at the Gartner reports Oracle, dB2(ibm) and MS Sql server are the top three RDMS in the marketplace. In researching this topic I found this link :

http://www.newsandtech.com/issues/2005/ ... abases.htm

I think the future is in rich web enabled applications available to the masses be it in a Corporate environment of a mid-sized to large company.. and to take advantage and to leverage the demand for that interface SQL seems to be the dominant back end of choice.

I would like to be able to look into a crystal ball and give eveyone the answer here .. In my environment SQL be it Oracle, dB2 and Sql Server are our back end investment of choice... I ( in my renegade IS shop ) am the only one running an ADS server.

Rick Lipkin
SC Dept of Health, USA

I agree with every word of Mr Rick Liptin. Yes, that is the future.

By coincidence, my experience is almost similar to him, except that I am retired now.