Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Considering changing my Vfp Apps as SasS Apps

Status
Not open for further replies.

stanlyn

Programmer
Sep 3, 2003
945
US
Hi,

I need insight, do's and dont's for implementing some of my vfp apps as SasS apps. To solve the uptime requirement for either the whole app, or just the licensing components, I'm considering Azure. Its uptime is far better that what I can provide.

So how would you implement? For now, I'm moving the licensing stuff to our sql licensing server with encryption. This server will be contacted on startup and give back to the app a go/nogo/trial answer. I'm also making provisions for it to be able to skip a few days in case the internet is down, but then lock it down after xx days with no authentication.

I'm developing it now, so nothing is set in stone. Discussion on anything related would be most appreciated.

Thanks,
Stanley


 
picking up on Olaf's mention of terminal servers .... you could offer your existing VFP desktop exe unchanged as a remoteapp on your own terminal server.

I offer a desktop exe as SasS through a hosting company in UK. Each customer gets a private folder for the exe and their database files with a licensed number of usernames (and an .rdp shortcut for their desktops) to login to the app on the server. If they stop paying their licence fee i can disable their account.

Works well for PCs and Macs.... technically possible to allow mobile (android/iOS) access as well but it's not pretty.


hth

n
 
>So are we back to creating our frontend as a desktop client and only serve user's data from servers in our control?
No, if you can afford the number of licenses or simply forward that costs to customers you can use VMs or terminal servers as your full frontend and backend. The typical VM hosting is giving YOU a server VM with IIS and Database server, as also is used in any web app, but at your full control, having the whole server at hand, and not just webroot folder for your scripts, html files etc and database connection, you have full administration as if it's your own server. But the hosting I think about rather is cloud hosting providing as many VMs as you need by demand and not only for your server adminsitration, developement and deployment, but as a full service to your customers. They run the same desktop as they run now, just not on their own system, but on your cloud side VMs.

As said the typical hosting is not that way and giving away logins to VM normally means you give away the login to your full server, that's not the intention of VM hosting. But as nigel says at last, it's working that way, their display becomes a remote display and everything else runs as now. Have you ever worked on a terminal at university, for example?

>It doesn't have to be as I'm seeing more and more browser apps providing identical experiences as found on their desktop counterparts
Well, web apps emulating desktop are not my goal, they only make sense, when run in the browser of a - well - desktop computer. I am using Office365, but mainly the license of it allows you to a) host some cloud side system holding all your mails in exchange, have a more professional one drive and some more, I use Word, Outlook, Excel, Powerpoint and these applications as desktop applications. Using the web outlook only sometimes to get at mail even at home. But not as main frontend. So the desktop like experience in a browser is far from perfect and doesn't really compare. One thing is true, when you go for web apps, you go for brwoser, and as said people don't like using mobile browsers, if you are on table or phone you rather want to use native apps, you rather don't have a keyboard. But even an app in a browser doesn't work for me as desktop app. No browser app emulates a desktop as said, and no multi form app running in several browser tabs lets it's form be positioned side to side on the desktop, even though browsers nowadays offer dragging a tab out of all tabs as a separate window. That tab window still mainly is a browsewr with all browser toolbars, etc. and even though that can be configured to not show, I can use forms of a normal desktop app the way they are intended right away without much ado, close and open up the same window configuration etc. I don't see Office 365 doing that at all or tending to go in that direction. The desktop experience still is it's own class.

>Forget my knowledge and build for the future? or ???

If your only knowledge is FoxPro, yes, forget about this language and its ways of working with data, get used to only having either SQL to get at data and also update and store it, or using Rest APIs CRUD (OData for example). What you can stay with it some kind of client side data object you're able to bind to controls (widgets), your new cursors might be json objects/collections, PHP arrays or the list of option tags they become in an html combobox, whatever. Still the main thought is not what makes up most VFP apps: client/server. You will not find someone taking over your business with a VFP application. You might still have much time left to make the move, I don't know, but it's not only time to leave VFP because it's lifetime is over, but becasue other languages and technologies offers good ways of rapid development. The entry hurdle always is high, for anything, but if you never take it, it won't shrink for you, there will be no new VFP, you are bound to die with VFP in its current state.

Even staying desktop outside of VFP means client/server today. XAML/WPF, even Winforms C# or VB.NET apps are only a frontend to a MSSQL Server, which introduces that typical client/server paradigm. Your other choice is Access. Access also is fantastic in some aspects, it's reports easily go to word or excel without needing XFRX or other third party components, Access is much more integrated in the Office desktop apps than VFP.

Bye, Olaf.
 
Hi Olaf,

Olaf said:
If your only knowledge is FoxPro, yes, forget about this language and its ways of working with data, get used to only having either SQL to get at data and also update and store it, or using Rest APIs CRUD (OData for example). What you can stay with it some kind of client side data object you're able to bind to controls (widgets), your new cursors might be json objects/collections, PHP arrays or the list of option tags they become in an html combobox, whatever. Still the main th..................

Yes, I know this and it is depressing...

If I were to quit FoxFro cold turkey it would take far too long before being able to create billable work, which is not good.

I'm thinking the best route would be to continue use vfp for all the frontend stuff while replacing all the dbf stuff with sql.

Thanks, Stanley
 
It's a beginning to start client/server and sql heavy development with VFP frontend, sure. You might then like to go FoxInCloud to also offer a browser frontend.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top