View Full Version : Deployed App does not respond to Navigation Buttons

2016-02-17, 08:24
I am "biting off" Lianja in small pieces to see if I can get the hang of it. This is an extension of my journey into VTs. Have app with single form section populated by a VT with a dsn to VFP ODBC. Works as expected in Builder, so I wanted to test on the Cloudserver with an outside browser.

I Deployed the app and the database and VT tables to the Cloudserver because I understand that the deploy button in the Web App View only updates the app.

When I run Preview, it takes some time for the data to appear (it does take some time for the VT to load as I am doing a Select * for about 15,000 records), and occasionally a "server disconnected" appears, but then the first record's data loads. Looks fine, I still have some work to do on formatting. Anyway, pressing the next icon (on the Action Bar?) does nothing. None of the buttons seem to be functioning.

Ok, here's what I have tried:

Create second app in project, use Southwind, simple one form section, drag on table. Works great in Builder. Deploy from Web App View - works as expected...data problems?

From console, USE the VT in the Cloudserver (...\lianja\cloudserver\tenants\public\data\...) and it loads the data and browse confirms.

Kinda lost, should be in debug mode and web servers communicate problems in logs... Debug file empty, Error file empty, Log file just lists events as OK...

I am pretty sure it's ME and not Lianja, but I can't seem to put my finger on it. Ideas?

2016-02-17, 08:38
What you have discovered is that VFP does not support the SQL LIMIT clause which Lianja uses if it is available. It determines this heuristically when the VT is opened.

Lianja SQL, MySQL, and PostgreSQL all support the LIMIT clause.

MSSQL does not but we get round it using some other strange MSSQL syntax that we generate internally.

So, in other words, when selecting one record in a web form Lianja has to read the whole table and extract that one record.

This is a limitation of VFP SQL which does not exist in Lianja SQL.

2016-02-17, 09:20
Hmmm...OK so the limit is how Lianja keeps the speed up while delivering a navigation method that seems like it should be slow on a web server. Wondered how you guys managed that, cool. It looks like continuing with this will require a custom, non-NoCode approach? Something along the lines of a Search and return a small subset, kinda like LIMIT. Actually, that is the way the program functions today, without next, last, etc..., and is solely based on searches. I think I just made my learning curve steeper! Actually I have been studying Qt some and it has helped me better understand the way the UI displays, still looking for spacers... Onward and upward! Thanks

2016-02-17, 09:47
There are a lot of techniques involved in providing the performance in web and mobile including multiple async client operations, connection pooling and connection keep-alives. Even ODBC VT connections are pooled by the server.

If you can it would be better to convert the VFP database into a native Lianja database.