Deployment problem - ODBC

I am trying to deploy an application which uses ODBC connections, in a
number of places.   There is no connection string being constructed, as the
name of the DSN is not known until runtime, and also there are an unknown
nuimber of databases to which a connection is required.

    I can replicate the problem using a simple class, which only has an
instance variable 'connection', with its accessors,a nd one method

    initialize

            connection:= DBConnection new open


When deployed this, says that it is dependent upon the Development
system,and gives an err


    'IM008 [ODBC Driver Manager] Dialogue failed.'


    I have tried to find the problem through debug stepping through the code
but to no avail.

    Can anybody throw any light on it.



    Ron

Ron,

There are two separate problems.

> When deployed this, says that it is dependent upon the Development
> system,

This has been mentioned in the n/g before and is down to the Database and
System Inspectors being a bit too closely related.  A previous response from
Andy Bower read -

~-~-~-~-

There is a problem as you suspect with the DB connection in Dolphin 4.01.
There are two ways to get around it. The first, although not strictly
"legal" (since it would allow some of the development components into the
runtime) is to simply ignore the message. This is the simplest approach and
I guess is the one used by most people deploying DB apps to date. If you do
this you should find that your deployed app works as normal providing you
don't make use of the Inspector subclasses.

The other approach is to do what you suggest and to split the DB Connection
package into two. Indeed this is the approach taken in Dolphin 4.5 (the next
scheduled release) where we have two packages, Database Connection Base and
Database Connection. The "base" package contains the runtime code leaving
only the development classes and methods in the other package.

~-~-~-~-

>              and gives an err
>
>
>     'IM008 [ODBC Driver Manager] Dialogue failed.'

This _appears_ to be associated with the "hwnd" parameter in the
DBConnection>>open method. Specifically, if you pass nil as the argument, as
you do in your example, then something further on complains.  When you run
the code from the development environment than the handle for the currently
active view is used so the error doesn't occur. (see the above method for
details)

You can test this by making the class you deploy a subclass of Shell and
adding one method

onViewOpened
    super onViewOpened.
    [   Processor sleep: 1000.
        DBConnection new open] fork

The forked block is just to ensure that the Shell if fully created and
opened before trying for the DB. There are other ways but this is the
simplest. If you remove the forking then the DB is opened before the Shell
and the error still occurs.

NB. You will also need a RuntimeSessionManager subclass whose #main method
opens the above Shell subclass and deploy using Package based deployment.  I
can mail you a demo package if you like?

>     Can anybody throw any light on it.

I wouldn't call the above "light", maybe a "glimmer".

You don't say how the DBConnection opening fits into your actual code, as
opposed to the example you gave, but the above might seems to suggest that
you will have to have a view open before opening the DBConnection.

Regards
    Ian

Ron,

>     Can anybody throw any light on it.

To turn the wick up a fraction more ...

MSDN includes the following information about the hwnd parameter in
SQLDriverConnect

WindowHandle
[Input]
Window handle. The application can pass the handle of the parent window, if
applicable, or a null pointer if either the window handle is not applicable
or SQLDriverConnect will not present any dialog boxes.

I *think* that is saying that you can pass a nil handle if you haven't got a
parent and/or you don't want the API to open up the dialog. The implication
being that if you *do* want a dialog, as you do, then nil is not a valid
parameter and you have to provide a window handle.

Ian

Ian,
    Thanks for the replies.

    I have now been able to get the application deployed, using your first
mail.  I had to create another opening window as the others are all looking
for items in the model, and it does not like the fork.

    So by having an initial 'splash screen' I can get the ODBC connection up
and running.

    You have seen the bulk of the application prior to this query.  I have
just added more functionality, so that now it will obtain tables/field
names; tables/store procedures; tables/indices and all appropriate file
names as well. It then can display how the tables/fields and programs are
linked.  This will be used in both a support role and in development.

    I had to allow the users to one any named database to hold the data as
Access can be a bit iffy when there are large quantities of data.  One query
was taking 18000 millsecs until I rewrote it,it now takes only 85 millsecs.
We have a fair number of databases at work, mainly SQL Server but there are
others such as Oracle and Access.   Some of the databases hve between 200 -
700 tables.

  Once again thanks for the help.



    Ron



Ian Bartholomew wrote in message ... a