Where to store database ID

[Peter Haworth]

I definitely wouldn't hard code the DBID!  Just go with Mike's suggestion
and write some general purpose handlers that actually issue the LC db calls
and put them somewhere where they're always callable from anywhere else in
your stack (main stack script for example)  If you do that, you don;t even
need to use a global to hold the DBID, a script local variable will do it.
 And you'll have a set of reusable handlers.

I think you also asked when the DBID gets cleared and the answer to that is
when you clear it.  In other words, your handler that closes the database
would set it to empty.

SHould also mention that there are techniques that call for opening more
than one db connection to the same database.

Pete
lcSQL Software <http://www.lcsql.com>


On Thu, Jul 25, 2013 at 9:34 AM, Pascal Lehner <tate83 at gmail.com> wrote:

> Hi Mike
>
> Thanks for the reply, it seems I can do less :-)
> I got into the habit of doing it that way when I first experimented with
> sqlite and DBLib and noticed that I get a new DBID everytime I reopen the
> stack.
> So I basically could just set the global to 1 and this works, as long as I
> just use one DB? When using two different ones, would I just use 1 and 2?
>
> I figure since it is a local DB it does not require a unique key or
> something (which 1 or 2 are not really, anyways..).
>
> Best regards,
> Pascal
>
> On 25 July 2013 16:07, Mike Kerner <MikeKerner at roadrunner.com> wrote:
>
> > I think you are overthinking this.
> >
> > IMHO, globals are far more convenient for the DBID.  The DBID does not
> > really expire, especially for SQLite, where you are not connecting to a
> > server.  When you close your stack or .  The only time the DBID is going
> to
> > be different is if you open different DB's in a different order.  If you
> > are only ever using 1 db, then the DBID will always be 1, but you still
> > have to tell LC to open the DB when you open the stack, obviously.
> >
> > What I, and probably most of us have done, is to write some DB functions
> > and handlers, so that I can pass the tables and columns that I want, and
> > the functions/handlers use the DBID and call the LC functions to actually
> > process the query.
> >
> > If you are using a function/handler to do your database interaction, then
> > it doesn't even matter how you have the DBID stored - in a field, a
> custom
> > property, a global, some array, or anything else, because the
> > function/handler will be the only place that needs it.
> >
> >
> > On Thu, Jul 25, 2013 at 10:56 AM, Pascal Lehner <tate83 at gmail.com>
> wrote:
> >
> > > Hi all,
> > >
> > > I am working on a project with a SQLite DB and I'm wondering if there
> is
> > an
> > > improvement to the following:
> > >
> > > On preOpenStack I connect to the database and store the connection ID
> in
> > a
> > > custom property on the main stack.
> > >
> > > In whatever command I  write or execute where I use any sql command to
> > read
> > > or write data, I always have to get the connection ID from the custom
> > > property and put it in a local variable as the first thing of this
> > command.
> > > This means I repeat that "put custom variable in local variable" quite
> > > often..
> > >
> > > Is this the right way or would you probably store it once in a global
> or
> > > so? Also, when does this connection ID expire and I need a new one? How
> > can
> > > I recognise that before the DB returns an error?
> > >
> > > Cheers from foggy Edinbra..
> > >
> > > Pascal
> > > _______________________________________________
> > > use-livecode mailing list
> > > use-livecode at lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> >
> >
> >
> > --
> > On the first day, God created the heavens and the Earth
> > On the second day, God created the oceans.
> > On the third day, God put the animals on hold for a few hours,
> >    and did a little diving.
> > And God said, "This is good."
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>