Closing a View Generated a Busy Error

[stanlyn]

Hi,

After changing some data I issue a tableupdate() and a few line later I issue a "Use in select("remoteview')" which generated error "Connection name is busy. Here ia a snip of it. So how is this different than with .dbfs?

Thanks,
Stanley

 

[stanlyn]

Hi,

After commenting out the highlighted line above it gets stopped again lower in the code at a SQLDisconnect(0)
command with same error.

Thanks,
Stanley

 

[Chris Miller]

Your USE of the table and you disconnect can mean VFP gets activ in flushing out changes automatically. And that fails on a busy connection.

I think I already said in one of your other thrads before closing a view make sure it has no changes buffered by either committing (TABLEUPDATE) or reverting (TABLEREVERT) them.
And do use the parameters as it best fits. Default without parameterization is only acting on the current record, you normally want to commit all data.

Chriss

 

[stanlyn]

before closing a view make sure it has no changes buffered by either committing

So, are you suggesting that after closing a view, some or all of it is still hanging around? I was expecting it to all be closed once gone from the datasession window, just like all other cursors and dbfs.

Stanley

 

[Chris Miller]

I said when there are still changes buffered or cached, these are taken care of. And of course for a remote view that needs the connection, and when that is busy, you get that error.

Chriss

 

[stanlyn]

Chriss,

Lets try this in a different way as I'm having a hard time reading between the lines...

So, are you suggesting that after closing a view, some or all of it is still hanging around?

true or false? (like stuck somewhere between the closed view and sql such as a buffer) Remember at this point they are not showing in the datasession window. How would I get back to the session waiting to be updated or reverted if they are not showing in the datasession window. If they are in the window, a simple "select viewname" does it, right?


I was thinking that once a view is closed and its name has been removed from the datasession window makes the closed session inaccessible. If I open it again, it creates a new and different session with no ties back to the previously closed session.
true, false, close, way in left field.


So is it possible for a view to be closed in the datasession window with data waiting to be written or reverted?

I was expecting it to all be closed once gone from the datasession window, just like all other cursors and dbfs.

true or false?

Thanks for your patience...
Stanley

 

[Chris Miller]

The error is about the connection, not about the workarea.

But the error implies, that something is done through the connection. The only thing I can imagine is buffers are flushed/written to the remote database.

You are saying this error appears when the workarea already is closed? That's weird.

But regarding your questions and wanted answers:

1. So, are you suggesting that after closing a view, some or all of it is still hanging around?
No, before closing a views workarea.

2. How would I get back to the session waiting to be updated or reverted if they are not showing in the datasession window. If they are in the window, a simple "select viewname" does it, right?
No, the session is your connection and you don't have one per workarea, closing the connection ends the session, not closing a workarea.

3. So is it possible for a view to be closed in the datasession window with data waiting to be written or reverted?
Just checked it. Yes, you can close a workarea with buffered data.

I don't know what exactly is happening, can you please show your code?

I only have one tip for you: Do not rely on TABLEUPDATE succeeding and checking its result. Look at its parameterization and the way it enables to get an array of error informations, ie use the full parameterization.

Chriss

 

[stanlyn]

Hi Chriss,

and you don't have one per workarea

Is this a typo? Should it read "and you only have one per workarea"?

Sorry for a late reply. Electric service just restored after a 3-day outage due to ice storms. (Kentucky, USA)

Thanks,
Stanley

 

[Chris Miller]

No, I mean you don't have a connection per workarea.


Chriss