Approaching Omnis again scares me, too much to learn?

[Alex Clay]

I would add developing solid reconnect code to this list. Eventually, users will want to access their data over a remote connection. That this connection will fail is a matter of "when", not "if". Your code for communicating with the database needs to be able to detect and report a disconnected session and potentially reconnect to your database. But more important, your application needs to expect database calls to fail and then handle those failures gracefully.

This is where RESTful data access really shines. RESTful APIs bring a paradigm shift of how you model and interact with your data. Endpoints and HTTP verbs are not the same as DML and SQL relations. But the real advantage is that RESTful communication is (mostly) non-stateful and doesn't require a persistent TCP connection to a server to maintain a database session. This means that if you 1) make a successful call to the server, then 2) the next call is unsuccessful because the network is down, you can 3) retry and, assuming the service is back up, get the exact same data. No logons, no sessions, no hung TCP sockets. This also _really_ shines for scaling your application and managing failover between servers.

It doesn't sound like you're planning to operate at this kind of scale, but IMHO you won't get far without running into at least remote data challenges. The modern "3 tier" approach of database -> api -> application evolved to meet user expectations for alway-available data accessibly across any device. Omnis can definitely be a part of this, but perhaps not all of it. That's a discussion for another thread, but for your immediate challenge, try integrating Omnis with an existing RESTful web service to play with and learn Omnis as a front end. Or, if you want to keep your DML skills, wrap DML calls into a Omnis-based web service and try using another client to access them. For basic development try a fancy RESTful API client like Postman, then take your pick of any front-end, including Omnis to build a GUI.

Like anything, find a project, tear into it, and learn by doing. The internet was built by and is run by our fellow geeks, and we love talking about problems and solutions. In 1995 a small office, LAN-based vertical market application could be solved by a single tool and managed by a single developer. You can still be a single developer in 2018, but you have more tools from which to choose and you can take advantage of the fact others have solved the problems you've encountered before. Instead of trying to approach "modern" Omnis development and understand it as a whole, start with a specific problem or project and learn how to best apply Omnis and other technologies to it.

We'll be here to help!

Alex

P.S. And don't forget to add tests so you're not burning your time fixing bugs! ;) (https://github.com/suransys/omnistap <https://github.com/suransys/omnistap>)


> On Jan 3, 2018, at 23:56, Chris Ross <chrisross at caliach.com <mailto:chrisross at caliach.com>> wrote:
> 
> Hello all,
> 
> DML to SQL. I have been through that process on our 35Mb ERP system (58 clients around the world - 3 to 45 users) and it has been a long and painful process. Some key points from our experience:
> 
>  *   Do the research first. I took over a year off to do that alone, but it did pay off!
>  *   The actual conversion took over 2 years.
>  *   It's not just DML replacement, more tricky is removing the CRB (current record buffer, e.g Load from list, etc. and reports.)
>  *   Make sure you re-write for Transactions (begin - commit - rollback) from the start as they are hard to re-structure for later.
>  *   Be prepared for client resistance to upgrade. DML is much simpler. Large sites gain more than small ones from SQL. We took the approach of no program functional changes (so testing was easy) but to clients "if there is nothing new, why the hassel?" Don't expect to make money from upgrading clients.
>  *   You and your staff need to be willing and capable of supporting a more complex internal beast. We missed that as a risk factor leading to at least one nervous breakdown (I joke not!)
>  *   Having gone through the pain, the results are worth it. Much more reliable, super-fast, coherent code, expandable and scale-able.
> 
> Best regards, Chris