View Full Version : Desktop app using mySQL and V12


09-29-2014, 05:42 PM
All of my experience with Alpha has been with web development.
Now I have been asked to create a desktop app with mysql and I'm at a loss of how to start.
I know I want a grid and I have developed that. It works fine in Working Preview but if I try using Live Preview I get an HTTP 500 error which if I view in Chrome shows:

Script Error
Error:Script:" /LivePreview/Cemetery1_LivePreview.a5w" line:56
x_out = a5_ajax_grid(tmpl)
WebSecurity: User is not found

I don't even have Security turned on. Nor do I have Users. And I thought these only applied to web apps.
Looking up Live Preview in the docs, I found only one entry and it had to do with using any installed browser.

So I guessed that I needed a form to put the grid on but I can't create a new form because Alpha says there are no tables in this workspace, in spite of the fact that I have a grid designed.
I have noticed comments on the forums about how Alpha has deserted desktop developers. They didn't mean much to me while I was developing for the web but now I know what they mean!

Maybe I've just been working too hard and the solution is obvious but at the moment I'm stumped.

09-29-2014, 10:42 PM
Wish I could help you. I do only desktop in alpha. Never had a need for a grid or sql. I use only dbf on desktop and create forms for it to input. V12 is much better than v11 for desktop.

09-30-2014, 01:34 AM

The desktop forms require a table. Create a DBF called menu. I have a single record in my MENU.DBF that contains constant information, such as the (owner's) name and address, counters, etc. You can use this as your base table then add your calls to MySQL. Hope this helps.

Ted Giles
09-30-2014, 03:58 AM
You need an SQL database with the tables and fields defined.
Then, go to the DT Control Panel and Add a Table.
Select the Passive or Active link and connect to the SQL Db.
You will now have a table, on which you can build the Form.

The Dt form is simply a front end replication of the SQL table and is used to update that table, but you need a copy of the table on the Dt..
It really works very well once you get your head around it.

Just remember that the application needs to be Dt, and will be using the SQL Db as a repository. So you will have 2 things to contend with.
SQL backend will be a lot slower than native DBF, and you can still use grids with DBF. Possibly a rethink needed?

Al Buchholz
09-30-2014, 11:03 AM

I would add that all objects should be built on a set. Even if it's a one table set.

A passive link table rebuilds the table during a refresh and that wipes out objects built on the table.

Stan Mathews
09-30-2014, 11:11 AM
An alternative to passive and active link tables is to create the tables you want in Alpha (native dbf) and empty and refresh them with SQL::ResultSet::ToOpenTable() as desired. This preserves the layouts you create.

Ted Giles
09-30-2014, 11:40 AM
Now all we need is the originators response.

Steve Wood
11-03-2014, 09:54 AM

I too would be interested to see how you have done since this post. You CAN build a desktop application, that runs in RUNTIME, that is fully SQL (with no "active link table) and is 100% web components*.

* You need ONE dbf based form to create the main menu, but that is the only DBF/desktop object you need. Web Security is NOT applicable in this scenario, not sure how you got your original error message.

Here is a video of my work in this area: http://www.screencast.com/t/c9pqRIs6Nc

Tim Kiebert
11-03-2014, 10:09 AM
Hi Steve,

Great overview. Thanks

Al Buchholz
11-03-2014, 10:11 AM
* You need ONE dbf based form to create the main menu, but that is the only DBF/desktop object you need. Web Security is NOT applicable in this scenario, not sure how you got your original error message.

You can build an xdialog based main menu and eliminate the need to base the menu on a dbf table.

Including the web menu using the html object in xdialog.

Steve Wood
11-03-2014, 10:27 AM
I just noticed I need to redo this video! I watched it for fun, and at 2:49 is shows all of the DBF tables and says it "is a DBF-based application". It started out that way, but is fully SQL now!. Since then I have also added an Installer that pulls down the Alpha RUNTIME from my website during install, and sets up their MySQL database as an initial step.

I should say that, although this "Desktop/Web app is cool" just like in the days of distributed desktop software, having this software reside on the client's machine is a pain compared to running as SaaS. In this case the client mandated it because of the sensitive nature of the data. But like all things, that position is softening over time and the client is considering uploading their data to our server and then we can avoid putting the software on their machine.

11-06-2014, 12:04 PM
Wow! It's hard to believe a month has gone by since I posted this question... and the project is now a month behind!
I really must apologise to all of you who offered help. The reality is that I am the IT department for about 35 businesses and 15-20 individuals and October brought a rash of clients updating from Windows XP. However I'm now back in programming mode so here is an update on where I am.

The original application which I have been retained to update is old, visually ugly, and written in M/S Access with a poorly designed database. On the other hand it is relatively simple and has only one table and runs on a single machine (although they would like to add read only access from an additional workstation).

Ted: Following your instructions, I can now access the mysql database from a desktop form.
You may be right about a re-think being required. I have over 30 years experience with dBase, Clipper, FoxPro, and xBase++ so I'm quite familiar with the environment. I originally considered converting the app to use mysql because that is what I have used exclusively for my web programming - and I haven't really missed the necessity of writing a re-indexing routine for every program to look after the inevitable problems due to index corruption caused by improper shut down, etc. Data security also seems better in mysql.

Steve: Thank you for the video link to your Data Blender app. It was very helpful and looks like a good starting point for WCD's. BTW, the error I posted was due to trying to use Live Preview for a desktop app and there is of course no server running.

It appears that desktop programming with Alpha involves another whole new learning curve and the Help files seem next to useless for that purpose.
Virtually every program I have written has been net workable and multi user without any changes to the under lying code so the division of server side and client side programming requires some adjustment on my part. Also, I come from a very object oriented background so this genie oriented code generation is somewhat foreign to me.

Again, thanks to all who offered suggestions.

11-06-2014, 01:06 PM
Having also come from dbase, clipper and others. I do not understand why not dbf files. I have many apps out there written that have no security problems since I can lock tables(table encryption). No index problems. dbf is faster on a desktop than sql. Forms/reports/etc all work faster. There is no problem with a second set of eyes/computer(s) in read only mode or working mode.

From what you have described, it seems a simple job to convert to native dbf in alpha, build the forms and other to be done. encrypt and table that has need and go on.
I can build what you have described way faster than anyone using sql. It will also run faster and be as secure as the system it is on.

Either way, Good Luck.