FiveTech Software tech support forums

Hi Otto,

I have absolutely no problems with DBFs over networks. I haven't in many years.

The issue here is SQL. Personally I like DBF's, but in this increasing world of connectivity, they simply are not being supported. If I need to make ancillary programs for some capabilities, they need to be in SQL. Many of the 3rd party programs have built in features for SQL ( like Codejock ) that simplify the usage, but not for DBF. As I look to the future ( optimistic for this old timer ), I know I should make the transition.

Remote desktop may work for you, but I don't see a need for it in my case.

Finally, if I decide to do a cloud based solution, SQL would be, by availability, the database of choice.

I'm just thinking ahead, keeping the senility at bay !

Tim

Hello Tim,
this is strange. Here we use XML for this.
Best regards,
Otto

I love ADS. I can use SQL interface/client and straight DBF access on the same data at the same time. They even have an oData client for use with mobile connectivity.

Hi Tim

I agree with you.

Long pass through this stage and the complexity of my applications just like you, we have due to our customers, to go from dbf to sql was a decision to mediate and end we decided on SQLRDD and xHarbour, it took three months to put about one of our most important applications.

however, now we want to use new tools like visual strudio, xHarbour does not even for visual support.

So we're in the same position we had 5 years ago, when we migrated to SQL because SQLRDD is not even supported for Harbour.

So we have to decide just like you, that tool allows us to have a reliable solution in short time.

Analyzing the different options, everything points to ADO, however, the change is substantial, due to the change in how you view the information from a DBF table vs. SQL, when already in production and should not affect our client and we estimate that the change will take us 6 months.

And all this because of the incompatibility between compilers, (x) Harbour.

regards

This is a discussion with many viewpoints. I posted it because it is clear that many FWH developers are facing the SQL question. Certainly Daniel has made some nice contributions with Dolphin, and Rick has excited people with ADO.

I am working on the belief that FWH + Harbour + MSVC ( Visual Studio ) will be a major benefit for us. I also believe that when we use Visual Studio, we will see the benefit of using other languages to build supportive programs for our main programs written with FWH.

Visual Studio does not natively support DBFs any longer. That is why I'm concerned. In fact, as I talk with IT people now, most really don't know or understand DBFs. They only use SQL to store data, and XML to share it. Most of the 3rd party programs with which we have to interface only use SQL. ( These are products that provide data to our clients ). Also, at my age, I always have to think of someone taking over this code, and SQL would be a lot easier for someone to acquire and use. Its just the way it is today.

Yes, ADS is good, and my main system uses ADS. However, to be honest, the company has been acquired many times and the staff is changing. There is no guarantee it will be around for the long term. Its a very small segment of a very large company. My rep is gone, and the new person responsible for providing me product to sell doesn't seem too interested. That concerns me.

This is a huge project for me to undertake so I like any options to make it easier. When I went to tData ( objects ), it was a lot of work, but it was very worthwhile. Hopefully I can find a way to make a smooth transition and have a result that attracts new clients and pleases the long term loyalists.

Tim

Tim

I remember when I modified my first DBFCDX application to Sql Server with ADO.. I found it to be a different way of thinking, especially thinking in terms of fetching a subset of rows for a specific query, rather than opening an entire table, seeking and filtering data.

One thing to keep in mind using recordsets is that they are local ( cached ) to the workstation that opened them and in a multi-user environment you need to keep in mind data visibility. Meaning, if I have a workstation that has fetched a set of rows from a Customer Table and workstation two has done so also, but has ADDED a new record .. workstation one can not see the new row until he refreshed his cache of records... to handle such events you need to plan for them in your development to open\close and re-open tables on each workstation as you move from module to module in your code so that you have record visibility between your workstations.

Also, in many service shops you many have 10 or so ( open ) work orders in a day and you can have multiple people ( potentially ) modifying the same record at the same time so you need to account for that before you update any records to make sure you do not over-write records that have been 'out of your scope' ..

I have all kinds of strategies I have dealt with and the time to think about ( especially ) workstation update and visibility is at the planning stage and not a retro-fit after the fact.

If you like we can share some code, or I would even be willing to take one of your small modules and covert the code in your context so you can see how SQl and Ado work together.

Rick Lipkin

Tim,

I reviewed my old recordset class and notes and was going to point out some of the issues when using SQL, but I see Rick has already mentioned most of them.

So, although, my recordset class can be used as a drop-in replacement for the TData class, you cannot feasibly do this when using large tables since the entire table must be in the recordset. Therefore, there seems to be no alternative but to rewrite code in order to move to SQL databases. Mainly you need to reduce browses to only a subset of a table which generally can be done with a search narrowing down the number of records to be browsed.

Then as Rick pointed out, changed records in the set must be updated immediately so other users can see the updates.

James

Hello,

Fivewin provides a set of great ADO functions created by Mr. Nages.

Also, Rick and Enrico provided me extraordinary help and support to understand ADO.

ADO allows us to use whatever database available with same code.

In the past, SQLRDD seemed a great tool, but at the end it turned out to be very buggy and unfinished. Also, Antonio pointed out in a previous message that Patrick Mast is considering to move into Harbour.

About ADS, Timm indicated the risk. Besides, the costs are quite expensive.

Lucas,

lucasdebeltran wrote:In the past, SQLRDD seemed a great tool, but at the end it turned out to be very buggy and unfinished.

I confirm. And moreover, it doesn't solve the problem of big tables pointed out by James.

lucasdebeltran wrote:Also, Antonio pointed out in a previous message that Patrick Mast is considering to move into Harbour.

This is not true. Patrick has confirmed in comp.lang.xharbour that he's not moving to Harbour.

EMG

I really appreciate the responses on this thread. It helps us evaluate potential options as we improve our solutions, and shows the pros and cons of various methods.

I like that people have many options, and make them work as desired. As a developer, I spend much time in communication with my clients. They don't understand programming, so they never tell me what to use. They do understand their business, so the let me know what they need. This allows me to understand where I need to focus in the next few years.

I always appreciate everyone's comments because they often bring up views that I have not previously considered, or cautions I need to explore before I make changes in my approach. I want to thank all of the people who participate in this forum for your continued input.

Tim