I just added a backup/restore functionality to my program, but after restore which closes all connections, I'm trying to rebind a grid and the select query crashes.

The only thing I can see wrong with the query is that the connection state is closed.

How can I surpass this hurdle? I guess I thought each time a getmulti is called it would create its own connection for that usage.

Some how getmulti is relying on the connections I closed to get exclusive access for the restore?

Thanks,

Terry,

Two quick questions to help us answer your question:

1) Which LLBLGen version are you using? 2) SelfServicing or Adapter model?

How exactly do you backup/restore? You serialize the collections to a file, and deserialize them back? Is this in the same application or in another application (e.g.: a different app as the one which saved the backup, so the .config file of that application probably doesn't have the connection string in it)

And lastly: what exactly is the error you get?

I am using self servicing. Version 1.0.2004.1 final.

I am using the backup and restore commands of tsql, not serializing, deserializing.

kill spid for all connections to database in question, from connection with master db.

exact error message is (partially as it is long): An exception was caught during the execution of a retrieval query: A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - The system cannot ...

As I said earlier, the connection is in state of closed. The app I'm backing up database is the app with the backup/restore in it. I am not backing up the collections, I'm backing up the actual sql server database.

Open connections that I guess are relied upon by my binding collections are closed before restore to allow exclusive access for the restore, so I don't know how to solve this, except by a separate form that has no use of llbl?

Hope not.

Very nice meeting you in Redmond, Otis, and thanks for taking some time out for discussing.

tvoss wrote:

I am using self servicing. Version 1.0.2004.1 final.

I am using the backup and restore commands of tsql, not serializing, deserializing.

kill spid for all connections to database in question, from connection with master db.

exact error message is (partially as it is long): An exception was caught during the execution of a retrieval query: A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - The system cannot ...

As I said earlier, the connection is in state of closed. The app I'm backing up database is the app with the backup/restore in it. I am not backing up the collections, I'm backing up the actual sql server database.

Open connections that I guess are relied upon by my binding collections are closed before restore to allow exclusive access for the restore, so I don't know how to solve this, except by a separate form that has no use of llbl?

Hope not.

SqlServer probably kills any connections during a backup to avoid locks being held by an open connection. So having connections open and doing a backup is a no go I'm afraid...

Very nice meeting you in Redmond, Otis, and thanks for taking some time out for discussing. Likewise! It was great to meet you in person finally

Otis wrote:

SqlServer probably kills any connections during a backup to avoid locks being held by an open connection. So having connections open and doing a backup is a no go I'm afraid...

I don't think so. SQL Server is designed for 99.999% uptime allowing you to run backups while it is in use.

Also, in order to run the backup command you must have a connection to the database.

Now, restoring a db with connections is another story.

BOb

pilotboba wrote:

Otis wrote:

SqlServer probably kills any connections during a backup to avoid locks being held by an open connection. So having connections open and doing a backup is a no go I'm afraid...

I don't think so. SQL Server is designed for 99.999% uptime allowing you to run backups while it is in use.

Also, in order to run the backup command you must have a connection to the database.

I didn't think of that, good point!

THough, Sqlserver isn't capable (as far as I know) of backupping data which is also in a live transaction. (as it doesn't have any MVCC system inplace). As far as I know / remember, could be different as well, hence my thinking of killing off connections.

Now, restoring a db with connections is another story.

That indeed could be the problem, as the complete catalog is replaced, e.g. the mdf file, which means that connections with the old file have to be killed.