This session concentrates on what I believe is one of the key missing puzzle pieces in Omnis when dealing with SQL database. While many of us piggy back on existing databases or use external applications to model data models and create scripts to apply changes to their database not being able to use your library as a leading source and pushing out
changes to your database during an upgrade.
We’ll first look at adding meta data to our schema classes to complete the missing information such as indexes, referential integrity, constraints, etc.
Then we’ll look at how to reverse engineer this information out of a database mostly focussing on how to do so in Postgres.
Finally we’ll look at how we can use this information to make a comparison with our schema classes to either pull new table changes out of your database into your application and how to push changes you’ve made in your library to your database.
We’ll also look at a few pitfalls and do’s and don’ts and have a discussion on how the added meta data can be used to speed up development of your application as well as it is now aware of how tables are joined.
If we have have time enough we’ll also have a look at views, types, stored functions and triggers.
In this session we’ll be looking at a few different ways to embed a help system to your Omnis application both within Omnis itself and interacting with external systems all hooking into the build in help handling.
system to your Omnis application.
We’ll first have a brief look at the build in but very limited help
system that is part of a default Omnis distribution.
We’ll then look into how we can replace this default help library with
our own so that we can use Omnis’ handling of the F1 key and thus use context sensitive help.
We’ll use this replacement library to look at 3 different sample implementations:
1) a help system build fully within Omnis
2) using a WIKI based help solution
3) using a Sphynx based help solution