ODBC: Is this a bug?

vfp 9, SP1

The point of the following was to determine if an ODBC connection is
available on the current machine and it works fine for that purpose.
However the added ? statements show what seems to me to be a bug.

? DBUSED('lms_logger') && returns .F.

TRY
USE (odbc_path+'lms_logger!header_view') IN 0 ALIAS test
rtn=.T.
CATCH
rtn=.F.
ENDTRY
IF rtn
USE IN 'test'
ENDIF

? DBUSED('lms_logger') && returns .T.
*
* However, if you try to create an SQL view at this point, it throws
an error
* that no database is open
*
CLOSE DATABASE
? DBUSED('lms_logger') && still returns .T.
OPEN DATABASE (odbc_path+'lms_logger)
CLOSE DATABASE
? DBUSED('lms_logger') && is now F

There is probably a better way for me to test the connection. And,
this is easy enough to work around. Still, it seems to be odd
behavior.

G

Dan
Thu Sep 20 16:45:52 PDT 2007

Not a bug.

When you USE a table or view in a DBC, the DBC is opened but isn't
necessarily made the "current" DBC. (It has to be opened before VFP has
enough information to even get an error. <g>)

CLOSE DATABASE closes only the "current" database.

Where you've commented that creating a remote view fails, I'd bet it would
work if you SET DATABASE TO lms_logger before trying. Your CLOSE DATABASE
would then work, too.

Dan

George Smith wrote:
> vfp 9, SP1
>
> The point of the following was to determine if an ODBC connection is
> available on the current machine and it works fine for that purpose.
> However the added ? statements show what seems to me to be a bug.
>
> ? DBUSED('lms_logger') && returns .F.
>
> TRY
> USE (odbc_path+'lms_logger!header_view') IN 0 ALIAS test
> rtn=.T.
> CATCH
> rtn=.F.
> ENDTRY
> IF rtn
> USE IN 'test'
> ENDIF
>
> ? DBUSED('lms_logger') && returns .T.
> *
> * However, if you try to create an SQL view at this point, it throws
> an error
> * that no database is open
> *
> CLOSE DATABASE
> ? DBUSED('lms_logger') && still returns .T.
> OPEN DATABASE (odbc_path+'lms_logger)
> CLOSE DATABASE
> ? DBUSED('lms_logger') && is now F
>
> There is probably a better way for me to test the connection. And,
> this is easy enough to work around. Still, it seems to be odd
> behavior.
>
> G

George
Thu Sep 20 17:53:52 PDT 2007

Seems obvious in retrospect!

Thanks

George

On Sep 20, 4:45 pm, "Dan Freeman" <s...@microsoft.com> wrote:
> Not a bug.
>
> When you USE a table or view in a DBC, the DBC is opened but isn't
> necessarily made the "current" DBC. (It has to be opened before VFP has
> enough information to even get an error. <g>)
>
> CLOSE DATABASE closes only the "current" database.
>
> Where you've commented that creating a remote view fails, I'd bet it would
> work if you SET DATABASE TO lms_logger before trying. Your CLOSE DATABASE
> would then work, too.
>
> Dan

Dan
Fri Sep 21 08:34:24 PDT 2007

They usually do. <g>

Dan

George Smith wrote:
> Seems obvious in retrospect!
>
> Thanks
>
> George
>
> On Sep 20, 4:45 pm, "Dan Freeman" <s...@microsoft.com> wrote:
>> Not a bug.
>>
>> When you USE a table or view in a DBC, the DBC is opened but isn't
>> necessarily made the "current" DBC. (It has to be opened before VFP
>> has enough information to even get an error. <g>)
>>
>> CLOSE DATABASE closes only the "current" database.
>>
>> Where you've commented that creating a remote view fails, I'd bet it
>> would work if you SET DATABASE TO lms_logger before trying. Your
>> CLOSE DATABASE would then work, too.
>>
>> Dan

swdev2
Fri Sep 28 11:40:05 PDT 2007

In addition to what Dan Said -

Why type of odbc connection is it ?
1. system dsn
2. sql connection inside o dbc
3. sql string connect somewhere.

Are you needing to test for the proper odbc drivers to be installed at the
workstation as well ?

Regards [Bill]

--
===================
William Sanders / EFG VFP / mySql / MS-SQL
www.efgroup.net/vfpwebhosting
www.terrafox.net www.viasqlserver.net

"George Smith" <grsassociates@gmail.com> wrote in message
news:1190328302.854005.218770@v29g2000prd.googlegroups.com...
> vfp 9, SP1
>
> The point of the following was to determine if an ODBC connection is
> available on the current machine and it works fine for that purpose.
> However the added ? statements show what seems to me to be a bug.
>
> ? DBUSED('lms_logger') && returns .F.
>
> TRY
> USE (odbc_path+'lms_logger!header_view') IN 0 ALIAS test
> rtn=.T.
> CATCH
> rtn=.F.
> ENDTRY
> IF rtn
> USE IN 'test'
> ENDIF
>
> ? DBUSED('lms_logger') && returns .T.
> *
> * However, if you try to create an SQL view at this point, it throws
> an error
> * that no database is open
> *
> CLOSE DATABASE
> ? DBUSED('lms_logger') && still returns .T.
> OPEN DATABASE (odbc_path+'lms_logger)
> CLOSE DATABASE
> ? DBUSED('lms_logger') && is now F
>
> There is probably a better way for me to test the connection. And,
> this is easy enough to work around. Still, it seems to be odd
> behavior.
>
> G
>