I just found out that whenever I closed any forms (in which I use remote
views), than the connection doesn't disconnect automatically. Is this a
normal behavior or do I miss something? I could not literally put
SQLDISCONNECT because there might be other forms use the connections.

I checked the connection using SQL Spy as I stated in my previous post.
On my forms, I use Private Data Session, connect to the SQL Server via
ODBC.

Please advice.

TIA,
Willianto

RE: After closing a form, a connection doesn't disconnect thoroughly by Leemi

Leemi
Tue Jan 04 15:29:12 CST 2005

Hi Willianto:

Do you close the remote view when you exit the form? Is the remote view
created via the View Designer or are you using SQL PassThrough code to
create it?

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003


>>I just found out that whenever I closed any forms (in which I use remote
>views), than the connection doesn't disconnect automatically. Is this a
>normal behavior or do I miss something? I could not literally put
>SQLDISCONNECT because there might be other forms use the connections.

>I checked the connection using SQL Spy as I stated in my previous post.
>On my forms, I use Private Data Session, connect to the SQL Server via
>ODBC.

>Please advice.

>TIA,
>Willianto


Re: After closing a form, a connection doesn't disconnect thoroughly by Willianto

Willianto
Tue Jan 04 19:56:33 CST 2005

Hi Lee,

First of all, thanks for responding and Happy New Year to you and your
family :)

> Do you close the remote view when you exit the form?
No. I use Private Data Session, and I expect VFP to close the view
and -thus - the connection as the user close the form. Am I right?
> Is the remote view created via the View Designer or are you using SQL
Pass-Through code to
> create it?
Most of my forms use between 2 to 10 remote views created via the View
Designer. My policy the apps would have to update some data (whether
it's insertion, update, or delete), then I use RVs. If what the apps
need is just a lookup data or read-only data, I prefer SPT. But there
are times when what I need is already on the RV, so I choose to open
another view.

Any idea?

TIA,
Willianto
"Lee Mitchell" <Leemi@online.microsoft.com> wrote in message
news:C9XF0Rq8EHA.2680@cpmsftngxa10.phx.gbl...
> Hi Willianto:
>
>
> I hope this helps.
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> Sincerely,
> Microsoft FoxPro Technical Support
> Lee Mitchell
>
> Keep an eye on the product lifecycle for Visual FoxPro here:
> http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
> - VFP5 Mainstream Support retired June 30th, 2003
> - VFP6 Mainstream Support retired Sept. 30th, 2003
>
>
> >>I just found out that whenever I closed any forms (in which I use
remote
> >views), than the connection doesn't disconnect automatically. Is this
a
> >normal behavior or do I miss something? I could not literally put
> >SQLDISCONNECT because there might be other forms use the connections.
>
> >I checked the connection using SQL Spy as I stated in my previous
post.
> >On my forms, I use Private Data Session, connect to the SQL Server
via
> >ODBC.
>
> >Please advice.
>
> >TIA,
> >Willianto
>



Re: After closing a form, a connection doesn't disconnect thoroughly by Andrew

Andrew
Wed Jan 05 06:22:51 CST 2005

Willianto wrote:
> I just found out that whenever I closed any forms (in which I use
> remote views), than the connection doesn't disconnect automatically.
> Is this a normal behavior or do I miss something? I could not
> literally put SQLDISCONNECT because there might be other forms use
> the connections.

Can't you just store whether or not something may need the connection
somewhere?

Then run a procedure when you close the form to SQLDISCONNECT if there is
nothing around that could need it.

Sorry if I'm way off, it's not anything I know about but from the outside
that seems to be what you need to acheive.
--
Regards
Andrew Howell