I realize that logon is this simple but…
Also, just to give a slightly longer answer specifically to your question.
oSQL is a class, I realize you’re taking your first steps into Studio
from your other emails? This is an analogy that I often use to explain
the core concept of OO that I find useful.
Think of a format in Omnis classic as a house, you create your format,
you add code to it, it’s the same as building a house, making the room a
certain size, adding windows, adding doors, etc. Once done, you have one
house, you can live in it. If you want another house, you have to build
another house. If you want to make changes to your house, it just
changes that one house, if all the other houses you build require the
same change, you need to change all those other houses too.
Think of a class as a blue print for building a house. You can’t live in
a blue print, you can’t place furniture in a blue print, etc. yet the
blueprint tells you everything about the house, the shape of the rooms,
where the doors should be, what materials should be used, where the
doors are, where the windows are, etc.
Making an instance of your class is akin to super fast building a new
house from the blueprint. You can build as many houses as you want from
the same blue print, each stands on its own foundation. Each is unique,
but they are all exact copies of your blue print with a little bit of
magic that if you change the blueprint, all your houses change at the
wave of your magic wand.
I won’t go into subclassing as this email is far too long already but
that is where the magic really starts to perform wonders.
So going back to oSQL, it is a class, it is a blue print that tells
Omnis HOW to communicate with a database. But nothing actually exists,
you can’t use the class directly, you first have to create an instance
of that class (think of instancing as building in our analogy).
You do that by defining a variable of type object and then assigning the
subclass to oSQL (there are other more flexible ways but using a
variable directly this way is the easiest and suffices for our situation).
Note that this is _not_ subclassing!! Subclassing is something entirely
Omnis will now create an instance of oSQL and that instance is the
entity you use to communicate with the database with. If you have
multiple databases, you may end up with multiple instances (i.e.
multiple variables) which all uniquely access one database. As most
applications only communicate with one database it is very often so that
you won’t need multiple instances of oSQL and many go down the route of
making their database connection instance a task variable so it is
available everywhere you need it.
This is why you prefix any method call with the name of the variable
that holds the instance of your class. As there could be multiple
instances you need to tell Omnis WHICH instance you want to logon to a
I could go on and write a few more pages on the subject, but this is a
start and probably the most important thing to understand in Omnis
Studio. In essence Omnis Classic was already object orientated but with
the limitation that each class only had one instance and that each class
only had one subclass but many of the paradigms already existed.
One last thing and that is about the term ‘object’ which is incredibly
confusing because it is often used very broadly. So some will talk about
an object when talking about a class, some will talk about an object
when talking about an instance of a class, and none are really wrong but
I would argue the latter group is more right.
When you are talking about “object” as the type of a variable then
“instance of a class” probably fits the definition best.
Finally, and again I could write pages about each of these:
A “session object” is an instance of a class that defines all the
behavior on how Omnis communicates with a database.
A “statement object” is an instance of a class that encapsulates the
behavior of executing a single query and getting its results.
A “table class” is a class that can be instantiated as part of an Omnis
list or row variable that “binds” that list or row variable to a table
in your database. It is responsible for creating the queries that
perform the needed actions in relation to your table in your database.
You need to use a schema class (which really isn’t a class but more like
a structure) to tell Omnis more about that table.
The session object, statement object and table class each perform their
role to create the whole process that allow commands like $select,
$insert, $update and $delete to work on an Omnis list or row variable.
For instance, when calling $select on your list it is:
– the table class that gathers the information needed to create the
correct select statement for your table
– the statement object that creates the actual select statement using
this information so that it is correct for the SQL dialect used by your
RDMS and handles the result set returned by the database
– the session object that actually sends this query to the database and
controls the information sent and received to/by your RDMS.
When you assign your (already logged on) session object to your Omnis
list variable (after using $definefromsqlclass to instantiate your table
class) Omnis will automatically request and create the statement object
this list/row uses. So every list and row that you have currently in
your application may use the same session object, but will each have its
own unique statement object. This ensures that the list A does not end
up retrieving the results of a $select done on list B.
On 13/1/18 9:54 am, Das Goravani wrote:
> Do tSQLObj.$logon(hostpath,””,””,libraryname)
> But I dont get why it’s done off the first item tSQLObj which is a subclass of superclass OSQL
> where this $logon is the built in logon function
> couldn’t it be started with just $logon
> Do you have to have an Object preceding it ?
> What does that do, to have an object preceding $logon
> Manage your list subscriptions at lists.omnis-dev.com
Manage your list subscriptions at lists.omnis-dev.com