VFP Data access to desktop and web clients 1

[naeempk]

Hi,

I need to access and update vfp data from desktop as well as web clients. I know sql server will be a good data source instead of vfp free tables but right now all our application data is in vfp.

I searched on web and in this forum about multiple techniques to do this which are like

(1) COM+ OR (2) Web service OR (3) 3rd party tools like WebConnect /
ActiveVFP / Foxweb (4) FIC (5) WCF / DotNet integration

Mostly these discussions are more than 8 years old. Is there any improved way to do this ?

And what will be the Data format ? XML or Delimited text ?

To pass multiple tables through XMLAdapter and concerns about large Data transfer through XML.

Any other point regarding this ?

TIA
Naeem

 

[Dan Freeman]

Creating a web-based application is really pretty simple. The client (a browser) requests a page, and the web server provides the page. ALL database action happens on the server side. NONE happens on the client side. The client NEVER has any direct connection to the data at any time.

Chances are good that your existing applications were not written with this model in mind so you're probably looking at a fair amount of new engineering no matter what back-end tools you use.

My suggestion would be to spend some time studying web client and server technologies. Decide on the data storage format later. It's mostly irrelevant once you've found the development platform that serves your needs.

 

[SytzedeBoer]

I have a client who needed 10 of his clients to access their information in a specific format.
I created a small application just for these 10 clients.
That was step 1, and very simple

Then I set up a simple Win 7 pc at my client's place (second hand) and installed TSPLUS
My client's clients are happy, my client is happy, and I have been very happy with TSPLUS

You can find tsplus at

http://www.tsplus.net

 

[JRB-Bldr]

A current client of mine is slowly migrating their own clients from a legacy VFP application accessed through virtual RDP 'workstations' to a web-based application. Both applications use VFP data tables (at least for now).

Since some of their clients are so familiar with the old VFP application and are therefore slow to convert, both versions of the application will need to continue to be up and running for a while.

For the web-based version of the application they are using VB.Net (VS2010) and accessing the VFP data tables through ODBC connections.

Good Luck,
JRB-Bldr

 

[naeempk]

Yes, It is an old style developed application and I want to convert its data access logic. I have seen some videos about Enterprise application development in DotNet in which they can access it through multiple clients like desktop / web / mobile / tablets etc and client applications developed in DotNet, JavaScript etc.

I also want to develop my app data access in the same way so that It can be accessed by multiple clients.

A few months ago, I developed a module in ActiveVFP which update one of my tables remotely via web as well as from VFP. It uses XML for data exchange. On server side there is a small script file which return and updates data. I want to make a single exe / dll file for all my data/business layer logic instead of several script files.

I need suggestions from VFP developers who have experienced in such development and deployment.

I recently purchased TSPlus so that I can shift my remote users to my existing application and mean while I will developed my data access layer.

I also purchased Lianja but for me it will take some time to develop applications using it.

Thanks
Naeem

 

[Olaf Doschke]

Dan is describing very well how a web application works, and that means new implementation. You may even stay with your backend, if you can move it on a windows based hosting platform and eg use ActiveVFP to build the new web frontend to your VFP backend.

>Mostly these discussions are more than 8 years old.

I don't know your sources. Anyway, HTML is 25 years old. Yes it's still developed and not static. But if you expect something only can be good, if it changes over time you're neglecting something not needing to change has the advantage of being stable and is no source of your own needs to adapt to changes. COM+ is COM+ and hopefully will stay this way, otherwise billions of lines of code writing COM+ components will need to be updates. COM+ rather compares to electricity. The innovation comes with your DLL implementing your web app, not with COM+ improvements. Like in electricity you can be thankful you can use the same plugs and don't need to adapt every year, month, day...

I won't address every technology you mention, but aside of COMü lets pick out the older WebConnect. West Wind is not developing this, but it works and has all the web protocols implemented, Rick Strahl is now a .NET developer, still very active. If the w3c will change http protocol (as probable as there will be a change of voltages and sockets in electricity), then Rick surely will also adapt to this even in this old product. I'm quite confident, because many things surely still are based on WebConnect.

ActiveVFP was invented about 2007. LAtest version is 6.03 from January 2013, see

http://activevfp.codeplex.com/releases/view/53030

You may have other things wrong, too.

Bye, Olaf.

 

[Olaf Doschke]

Just one more thought:

If you want to introduce the new web frontend to your data on most recent technology, you have to say good bye to your old DBFs, not just free DBFs, all DBFs. That will introduce costs in adapting your legacy application to handle other data, eg to adapt to a SQL Server also is a major change mostly needing a reimplementation.

Syncing data with a new backend is what one of our customers is doing, though the new db is not in the web, it's merely an inhouse MSSQL server instance in synced a DBC database. It's what they do themselves, but recently we discussed ways of doing so in your own thread thread184-1740547.

Even if you redesign the database in SQL Server you may add transformations to the staging of data and you have seperate worlds. Your legacy app works untouched, your new app can be developed independent from that, you're only bound to get the syncing right, unless new data is not needed by the legacy application.

Bye, Olaf.

 

[Mike Lewis]

Naeem,

You mentioned ActiveVFP. I would have thought that would be a good solution for you in this case. It will allow you to access and update your VFP tables using familiar VFP code, and you would be able to use all the features of the VFP IDE to develop and test the code.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

You don't have to say goodbye to your old DBFs, you can implement a very stable and reliable front end to an old VFP app using classic asp and the VFPOLEDB interface to
read and update your data. I do it all day, and it works really well. It's a cheap and fast way to get online access to your data.

No SQL, no licencing issues, just have to live with the shortcomings of asp

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

Makes me wonder, if you gave up the idea to sync your data, as you look for ways to bring VFP code to the web. If you want something new rooting in a sql server database I'd not opt for classic VFP or ActiveVFP or any VFP related web technology, just because you can code in VFP. What matches best to MSSQL would be ASP.NET and what would match a mysql server would be php. You need new contractors doing this frontend and won't be able to recycle code, but it will be headed to current and future technology. If you hire new contractors you're even forced to do so, if not finding VFP developers. Even if you're doing this on your own you have to think about what happens at your retirement.

Also only you know what part of your application is needed for the web. Do you really need a 1:1 adaption of what you have at the desktop? Or do you want to provide a web order form for end customers and services for suppliers? What is the goal? End customers surely will not need to manage and modify your stock list, product descriptions etc., so you don't need that part on the web in stage 1 at least, perhaps it would be a long term goal to retire the desktop application, but I'd let this grow naturally with normal tempo and not make a major leap, which could turn out to be a failure, even just if you dislike your new developers personally, so it doesn't even need to be technological reasons.

I see many companies taking advice to modernize software in a way promising fast ROI, proven conversions and more. For example I just looked at metex.com and while all they say seems practical, I dislike their way of modernization from a short glimpse. There is no VFP to JAVA or .NET conversion tool unless they built one themselves but I doubt results will really dust off legacy application design, and that isn't only meant visually. You have to think new ways if going web or mobile. It doesn't really help to only start from where you were and be able to make advances 4th generation languages don't offer, you have to design for new interfaces from the start and that may well mean you can't recycle much more than data.

I don't see anybody offering a more natural growth out of the legacy situation part by part. Even if a company has a bigger application landscape and migrating a full application is only a small subset of the whole landscape you always have a risc of failing with it. You could take the view of application domains, functionalities or even roles in an application. In the end it's all about your employees and the work to be done, not about the servers and workstations and the way the landscape is currently designed. Modernizing application by application is like replacing old machines of a machine park. Software isn't hardware and that thought hasn't striked management, if you ask me. I don't see that happening.

Bye, Olaf.

 

[naeempk]

Vfp data sync to a database server is an other part of this application. I want to use my VFP knowledge to build a single vfp data access layer for all types of clients like desktop / web etc. Yes, you are right that it is the data which will be common in all these clients. And all the data processing will be handle at server level and it will improve VFP data access speed and time. Eventually, I need to convert my whole application data access logic to a database like sql server.

 

[JRB-Bldr]

After having read over the information in the posting, you might want to look at:
FoxInCloud ( thread184-1738557 )

I don't like how it focuses its numerous 'challenges' against things Mike has said in the past.

And the posting "walks a very fine edge" near going over the posting rules ( Promoting, selling, recruiting, coursework and thesis posting is forbidden ) - meaning "Read it now before someone Red Flags it and it disappears".
Regardless it does have some information worth reading and considering.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

OK, let's take it backwards from
> Eventually, I need to convert my whole application data access logic to a database like sql server.
I thought this is the thing you're already doing, because the thread about syncing data is assuming you sync DBFs data with a SQL Server. If you are syncing LAN DBFs with Hosted DBFs you won't gain something for moving forward to other technologies.

>I want to use my VFP knowledge to build a single vfp data access layer for all types of clients like desktop
That's not the way you should do it. Using VFP code to access data will give you cursors and only a VFP frontend then can really do something with the data. So you go from dbf to cursor and then will need another conversion to XML or even put the data into HTML directly. If you want a modern future proof web frontend you won't use VFP technology. If you don't have any other knowledge, then you need developers or you don't go web in the form of browser apps but use terminal server. Then your app can stay as is and be used from remote.

The disadvantage of terminal servers is you need client cals, it only scales with hardware, you need RAM and CPU resources for every user. This partly also is true for web apps, but web apps can make use of client side code and javascript running on client workstation, not on your (hosted) server. So a web app scales better than an app made available remote by terminal server.

>all the data processing will be handle at server level and it will improve VFP data access speed and time
This is what you expect but it isn't true in all cases. There are advantages and disadvantages of server side processing. The simplest thing to consider is code executed on the server side will need resources per client, so your performance doesn't scale well, you have limitations of RAM and cores you can put into a server, if you want to scale on the server level by using more servers to have more ram and cpu resource you have to use things that are only well established with database server in conjunction with web and application or terminal servers, not with a databse consisting of hosted DBFs, even not SAN will help you with that problem on the file server level, so it's only a fast solution for a small user base.

The bottle neck for a VFP desktop app is DBF file access and only that, if you put your data access to the server side you do nothing else but implement a database server, you get request and respond to them. This is what a database server does and does better than you can implement it, because there is decades of knowledge about how to do that.

Here Claude Fox would say, that activeVFP does that very well, you can use your VFP knowledge to do the data access, but activeVFP is for creating web apps, not feeding desktop apps with data, so while it already can do data access quite nice it does so for creating HTML web frontends, which combine that data with HTML forms and HTML frontend. You can't recycle your frontend code here.

That said let's move far away from details and take it from requirements.

What you should first forget about is the need for centralised data. Depending on the number of users and number of locations you need different things and need to split at different levels.

You can split at the frontend level only by using terminal server/remote desktop. Users will use their input devices mouse, keyboard to control a remote server which will be running the app local in the LA#N of your database and everything can stay, but you need much server resources to serve many users. This is only good for a situation with main user base at a main location and only a few remote users.

You can do the inverse and run your desktop apps with local data at each location independently. You will then do data replication/syncing of all the local databases to one central data repository. This will not be the main database to any location, it will just be there to aggregate all data and also distribute it to all locations. It's best be done using a sql server database which has all the needed logic for database replication inside. How fast you need data at each location or from them determines how much you need to pay for high speed internet connections, private describer lines for example.

If you take the adventure of writing sync code with DBFs you still will rather replicate data to each location via a central location only there to provide data to each locations local database than what intend to do now.

The only good way to have central data for direct usage of many clients is really a cloud based database technology like Azure or and you can forget about your vfp knowledge both for data access and frontend. Even FoxinCloud only namely is a cloud solution. As far as I understand you still host at a single server. The cloud only is the cloud if your requests to the cloud app or data can be handled with multiple servers in different computer/data centers around the world which obviously therefore need to handle replication of all data and code in the cloud. The cloud therefore is more than just the internet. FoxInCloud, which referring to the recent reaction of them referred to by jrbbldr is taking .45 seconds per action. That's because every action is involving the server, FoxInCloud is not converting forms to html forms with code converted to locally running javascript as far as I see. So that unresponsiveness alone wouldn't suffice my needs and I doubt yours. And if you'd get their product for self hosting or installing on hosted windows servers yourself you'd still be bound to the bandwidth and throughput you can rent or host on your own. If you're intending to move forward you have to move away from VFP both for data and for frontend.

Also the global distribution of your location determines whether you need cloud or not. If all locations are within a country a classical web application can work well, but if your users are all over the world some central server will mean slow access for users at the other end of the world. Some hosters then may still be sufficient but it all will then depend on how much request you'll have and that's hard to determine by current desktop application code. the bandwidths of users are something you can't have under full control unless you can rent the needed lines at their local workplaces, if you have a global audience it's not in your hand what internet providers they use. Some have a very good bandwidth but less good response times/ping times, which would be essential for smooth responsive interactions.

And now I can be easily misunderstood if you put all this in your wrong idea of what several terms mean. For example responsive web design is not to gain better performance and responsiveness of a web app but to better respond to the different device resolutions and sizes. So if you're making management decisions without knowing details of terms and their meanings, have an overview of what technologies are, then you're bound to make false decisions.

Bye, Olaf.

 

[Olaf Doschke]

One more thing: I don't want to blame you for anything or consider you naive, but I've been asked what a sql server is by management, because they are even confused by the double meaning of the term server to describe both hardware and software products. Just as one note. I don't judge you in that category of management as you do develop your own software, but you are very specialised on VFP, maybe even older Foxpro DOS. Also in general I don't how large your company is and how large the application is you want to migrate.

From a more general perspective you can only get the best advice what to do to migrate your data and application or in other words your knowledge and work processes, if working together with consultants and go into your company landscape in a very detailed level. Important details can easily be overseen, eg only a desktop app can work very low level on any hardware like serial COM ports, if you need to use devices attached to COM. Printers are another problem via remote access, if you need a printed document locally, not remotely. And that's just two things you only ever stumble upon with experience and by factoring in all details into a overall migration plan.

I see you have got some things wrong already, but I may also be wrong about some of your interpretations and actions, in the end it's needing more communication and interactivity than you can get from a few forum posts. First questions are typically not just answered, but cause more questions about deteails you should really not need to learn yourself. And in the end the overall decision should be made by someone knowing both detailed needs of your company on the one side and detailed possibilities of technologies on the other side, which will not be a manager been teached about technologies for a few days, but a developers having been teached about your company for a few days. That may also need months or years. So the best advice to give here is to meet with a software vendor, at least with a freelancer developer, to discuss your needs a bit deeper.

Bye, Olaf.

 

[Mike Lewis]

I've been asked what a sql server is by management, because they are even confused by the double meaning of the term server to describe both hardware and software products.

I've seen that sort of confusion many times - not just by management, but also by developers (some of whom should know better). To add to the confusion, many people use the term "SQL" as a synonym for database, or even as a particular make of database: "We are migrating our data to SQL" or " ... to Microsoft SQL".

It's as well to remember that SQL is, first and foremost, a language; that SQL Server (with a capital S) is not a generic system or tool, but a proprietary product; and that there are other database products around that use SQL as their main language.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[naeempk]

Hi Olaf,

I am working in foxpro since foxpro DOS. I don't want to create a database server but wants to do some vfp data access layer. I have converted some parts of our application from vfp to oracle database too (mainly data for some reports).

I thought I could use VFP and XML(?) to exchange data between server and multiple clients. What other technology do you suggest ?

 

[Olaf Doschke]

Well, if you convert to an online database server I already said PHP is a candidate for MySQL and ASP.NET (c#) is a candidate for MSSQL. If you host DBFs then you are mixing technologies not really invented for one another. VFP comes with the soap toolkit and you can do webservices, but it's outdated and you should go in directions of C# based web services if it really has to be web services.

For VFP I'd always rather query the backend database directly, you can connect to a remote MSSQL or MYSQL database with a) the hoster allowing remote connections and b) the needed ODBC driver present as for the same database servers installed in the LAN, the only changes are the server part of the connection string besides perhaps installing a ssl certificate and ssl tunneling your database requests.

There is a reasoning not to make an exception for VFP apps going directly to the database, but going through XML and converting that on the VFP desktop side is cumbersome. Also web services should not just encapsulate data access. This may be were you start, but you aim for an API not providing data but the core functionalities. One of the manyfold questions I would have at this time is about details and there we go back to you needing consulting, not just a few forum answers. There is no single answer fixing all needs.

If, as I still assume, you put DBFs on hosted web space and add a soap based web service to read and write tables you're not 1:1 implementing sql and a sql server, but it goes in that direction and I'm not a believer of webservices as the tendency is noone is adhering to standards and so you also don't find developers capable to start from that level of data+webservice with their client implementation. RESTful APIs like OData are better suited but the core really would be a database server you can connect to, this is enabling more client side technologies.

Bye, Olaf.

 

[foxincloud]

Hi All,

@ Naeem

You can solve your problem using FoxInCloud:
1- Reuse most of your desktop code for your Web app
2- Same app behavior in Web or desktop mode - no need to retrain users
3- Data Entry in either grid or separate controls
4- FoxInCloud provides a VFP table or database synchronization tool (see screenshot further)

Don't worry whether the solution you'll choose is 'cloud' or not ... no more than a marketing gimmick.
The most important point is whether it's standard Web (standard HTML/CSS/JS), or proprietary, IOW whether users can use a standard browser without any additional installation or not.

You have many solutions to accomodate more users:
- up to 32 logical servers on the same physical server (provided you have enough CPUs)
- load balancing between several physical servers (

http://www.west-wind.com/presentations/LargeWeb/)

And there is a large difference between named users and simultaneouly active users. You often have (at least) a 1:10 ratio between the 2

 

[naeempk]

Hi Foxincloud,

Thank you for reply. I develop VFP desktop applications. As the internet is fast, cheaper and easily available, I would love to adapt my VFP applications to Foxincloud.

I have tried the demo version before and had these issues

1) Foxincloud tutorial and step by step tutorials are not available from other VFP users.

I know there are some videos and sample tutorials are available from your site but generally are not available from others especially from VFP community as we found other VFP related material.

The main point is that it should cut the learning time. Many VFP developers do not have any web development and web server configuration knowledge. It should be as easy as Foxypreview / ActiveVFP etc.

2) While my trial evaluation period (Foxincloud beta version) I had a problem and that time I was told that I have to buy the full product to resolve that issue. I tried to search that thread from west-wind (Foxincloud support) forum as a reference but could not find.

3) I have purchased webconnection version (5.0 ) and when ever I run "Foxincloud Studion Trial" version, It pops up webconnection version 4.0 shareware and registration message. How can I redirect it to use my purchased one ?

TIA
Naeem

 

[foxincloud]

Hi Naeem,

1/ Did you review

http://foxincloud.com/how-to.php?&howto=azTutoAll?

We are setting a documentation wiki where users will be able to contribute:

http://doc.foxincloud.com/doku.php

(under construction)

2/ As indicated in

http://foxincloud.com/download.php#trialForm,

FoxInCloud Application Server, Trial Edition, lets you test your adapted application on

http://localhost/.

FAS Trial Edition is limited to 10 forms, running in debug mode within VFP IDE
We answer all questions on the West-Wind message board.

3/ FoxInCloud installs a specific, compatible version of West-Wind Web Connect - you don't need to worry about that.
Whenever you buy the full FoxInCloud license, your West-Wind Web Connect license will be valid (we will ask you for that); you won't have to purchase a new one.