FiveTech Software tech support forums

Hi Kleyber,

Can you define Small Clients versus Large Clients in terms of records and conexion (Peer to Peer, Local LAN and Remote).

I mean how many records per months added to a table in order to consider using SQL instead of DBF?
What others criteria should us to consider to choice SQL instead of DBF?

George

George,

>What others criteria should us to consider to choice SQL instead of DBF?

If you are an employee and your company is doing a lot of transactions made by a lot of users, then SQL is the way to go.

If you are a developer and are selling a product used by less than 10 simultainous users, then DBF is much easier to handle. DBFs are handled by an "embedded database engine." It is all part of the application.

SQL client/server databases will require an additional install and someone knowledgable enough to administer it. If you are selling an off-the-shelf product, this is going to be an issue.

Cost is another issue. If you are selling a product for a couple of hundred dollars, then the cost of the SQL database engine may be a shock to your customers. It can easily cost more than your application.

SQL database support is another issue. Customers are going to come to you for support.

Regards,
James

Silvio wrote:DBF files run from 1984 from Asthon Tate , then DBase I, II, III, IV, Clipper

Silvio, only for curiosity purpose. Never have had dBase I. I believe first versión was dBase II.

Regards

This topic is interesting to me as I've been hoping to eventually start using a RDBMS to avoid the headaches that comes with users having a mixture of OSes (98,XP,Vista) that could result in data corruption but a couple of questions does arise. I hope you don't mind me using your previous post as a checklist James .


>If you are an employee and your company is doing a lot of transactions made by a lot of users, then SQL is the way to go.

Agree. Especially helpful would be DBMS that supports rollback on transaction. Data integrity would always be ensured even if there was a sudden power outage

>If you are a developer and are selling a product used by less than 10 simultainous users, then DBF is much easier to handle. DBFs are handled by an "embedded database engine." It is all part of the application.

The embedded database engine is what makes me itching to give Firebird a try. If I could get this to work, the same source could be used for running the app as a standalone or in true client-server environment.

>SQL client/server databases will require an additional install and someone knowledgable enough to administer it. If you are selling an off-the-shelf product, this is going to be an issue.

True, but I think we could minimize potential problem here if we design a setup that's not that complex such as dabbling with user rights within the DBMS itself, the rights to Views, etc.

>Cost is another issue. If you are selling a product for a couple of hundred dollars, then the cost of the SQL database engine may be a shock to your customers. It can easily cost more than your application.

The solution would be using open source and free DBMS such as PostgreSQL or Firebird.

>SQL database support is another issue. Customers are going to come to you for support.

This is where I think the showstopper most likely to be. In my case, I'd have to train the support staff on SQL. Not only that, she'll have to relearn everything she knows. Right now, any calls for support can be handled by her. She'll diagnose the problem, patch the data if necessary and forward to me only those that really needs tweaking in the source. If we do migrate, a lot of my time would be taken up in doing support job instead of programming.

I think that about covers my thought on the matter. As with everything else in life everything comes in twos. Each would have their own set of pro and cons.

Dear members,

I have used Clipper 5.01 with DBF and NTX files for the last 12 years. Till today I have NOT faced any data loss because of using DBF files. Offcourse many times I had faced problems due to NTX file corruption which mainly occured due to UPS failures.

To avoid/reduce problems which happens due to NTX corruption, I have followed a method. Everyday whoever opens the software for the first time, my software will reindex the dbf files. If someone tries to open the same application from a different PC on the network while the app is doing an automatic indexing, then it will give proper message to the user saying that "Automatic Indexing is under progress from some other PC. Please wait for N minutes"

I have used and still using my Clipper apps with DBF files in Novell netware platform as well as windows platform.

But the only problem which I am facing right now and that too only in Windows platform is that the users will be able to browse the folders containing the DBF files, delete DBF files if they go to the mapped drive containing the DBF files. Also they will be able to open the DBF files using Excel or similiar applications and modify the data. Most of the time we will become answerable to this vulnabarility

This I consider as a very serious draw back of using DBF files and I don't know how to getover this problem.

Whereas in RDBMS like MS-Sql, Oracle etc we can limit this problem to a very extent from the Client PC's in the network.

I am just sharing my experience.

Regards

Anser

I use DBF-files with the CDX for many, many years now.

I have application running in big networks with several GB on data.

I hardly have any problems. It's very rare that a DBF-file gets corrupted, now and then, a reorganization is necessary.

But to my opinion it is very stable.

To my opinion, I hope that DBF-files will be used for many years.

Hua,

>>If you are an employee and your company is doing a lot of transactions made by a lot of users, then SQL is the way to go.

>Agree. Especially helpful would be DBMS that supports rollback on transaction. Data integrity would always be ensured even if there was a sudden power outage

>>If you are a developer and are selling a product used by less than 10 simultainous users, then DBF is much easier to handle. DBFs are handled by an "embedded database engine." It is all part of the application.

>The embedded database engine is what makes me itching to give Firebird a try. If I could get this to work, the same source could be used for running the app as a standalone or in true client-server environment.

Hmm, Firebird is client/server not embedded. Embedded means that the database engine code is inside the application. Server software by definition runs outside the application. Is there some type of non-client/server version of Firebird that is embedded?

There is an embedded SQL database engine that is interesting. SQLite allows you to use SQL and even has transaction/rollback. All the data tables are stored in one database file. There is no need for any separate installation or maintence. It is also free. The downside is that it only has file locking, so any record update requires a file lock. This means that it cannot handle very many simultaineous users--how many it can handle is not clear. I have not been able to find any information about how many users it may be able to handle without getting too many locking errors.

http://www.sqlite.org

Regards,
James

James,

As a curiosity: the iPhone SDK uses SQLite

I would have to disagree with those who say MySQL is free. If you read the license, if you use it in a commercial application ( one you sell ), then you must pay a license fee.

Maybe you can download and use it and not pay, but then you violate the license and the spirit in which the product is developed.

I've looked at this many times, and the license terms are clear.

I don't write to SQL currently in my applications. However I use quite a few applications that do use SQL. Here are some things I've observed, and a few questions.

1) Generally the load times when starting these programs is much slower, and it would be appear to be related to functions accessing the table.

2) If an SQL database crashes, and I've had them do that, then what can we do to repair the file. I realize we could restore a backup, but what if just one small part of 1 table is damaged ? Is their a repair tool ? DBF's have dSalvage which makes repair very easy.

3) It appears that when I upgrade an application I use, often I have to upgrade the SQL version, and sometimes this creates problems with the data for other programs.

These are just a few observations.

Tim,

Where can I download dSalvage ?

Thanks.

Tim,

>
2) If an SQL database crashes, and I've had them do that, then what can we do to repair the file.
>

SQL provide "sentences" to repair the database tables.

i.e. MySQL can check for a table integrity and also can repair it if desired. Past weekend we used mySQLadmin to repair a table in these forums (the first time in three years of use of these forums). Nobody noticed it

Dbf would only need some fresh marketing.
I am sure some other companies would sell
the dbf format instead as database file as:

dbf - deluXe business file and would add another X.

Regards,
Otto

James,

James Bott wrote:>Hmm, Firebird is client/server not embedded. Embedded means that the database engine code is inside the application. Server software by definition runs outside the application. Is there some type of non-client/server version of Firebird that is embedded?

>There is an embedded SQL database engine that is interesting. SQLite allows you to use SQL and even has transaction/rollback. All the data tables are stored in one database file. There is no need for any separate installation or maintence. It is also free. The downside is that it only has file locking, so any record update requires a file lock. This means that it cannot handle very many simultaineous users--how many it can handle is not clear. I have not been able to find any information about how many users it may be able to handle without getting too many locking errors.

I guess going by your definition of what constitutes an "embedded" database, Firebird doesn't qualify. Though the term does get use a lot as I found here and here

SQLite does sounds interesting except for the locking part. I guess I can only give conclusive facts on Firebird or other DBMS when I've the time to dabble with it some more.

Hua,

I guess going by your definition of what constitutes an "embedded" database, Firebird doesn't qualify. Though the term does get use a lot as I found here and here

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.

If the client and server are both running inside the app EXE, then it is an embedded database engine in the traditional sense.

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

James