The Microsoft.NET framework addresses this issue. Opening a connection and holding onto it is largely a thing of the past. That being said, effectively the answer is yes. EntitySpaces like all other similar systems merely opens and closes a connection every time one is needed, and rather than holding onto it makes sure to do exactly the opposite, keep it open for the shortest time possible. Why? well, the .NET Framework has something called connection pooling, so when we close a connection it is not really closed, it is simply returned to the connection pool (still open). The next time we go to open a connection a the connection pool is searched based on the connection string (most likely a hash table lookup) and we are handed an already open connection. I hope this helps. I know VistaDB originally didn't have connection pooling but then they did add it. I'm not sure it is lightening fast however.

Our next maintenance release is going to yield some very nice performance improvements however (as per our latest blog post). 

Thanks mike, but bear in mind that I'm running it on the Compact Framework Version 2.0, and in this project I am running Windows Mobile 5.0. The CPU speed is 624MHz. It'll probably be a million times faster on a desktop machine anyway.

I was expecting to insert those records in about a second.

1    
2                    TblUploadLog uploadLog = new TblUploadLog();
3                    uploadLog.UploadLogId = Guid.NewGuid();
4                    uploadLog.DateTimeStamp = DateTime.Now;
5                    uploadLog.Success = "0";
6                    uploadLog.LogText = string.Empty;
7                    uploadLog.DeviceId = string.Empty;
8                    uploadLog.Actioned = "0";
9                    uploadLog.UserId = SessionManager.Session.UserId;
10                   uploadLog.Save();
11   

That, on it's own, just took 6 seconds.


Edit: I've just done a more accurate time check instead of counting in my head

1    DateTime start = DateTime.Now; *
2    uploadLog.Save();
3    DateTime finish = DateTime.Now; ~

* = 21:57:27

~ = 21:57:35

So, that's 8 seconds to save one record. 

Morning Mike, thanks for getting back to me.

I'm running on an HTC TyTn, running Windows Mobile 6.0. The speed on this is 400MHz with 64MB of RAM. I am also on another project that's running on a Socket SOMO 650, which is 600+ MHz and experiences the same speed problems when it comes to saving and loading.

Were your tests were run using the normal VistaDB Build 57? Have you tested using their corrected version that stopped the XML Exception, as per the post of mine that you made a sticky?

I ran this code again:

1    
2                    // Generate the upload record
3                    TblUploadLog uploadLog = new TblUploadLog();
4                    uploadLog.UploadLogId = Guid.NewGuid();
5                    uploadLog.DateTimeStamp = DateTime.Now;
6                    uploadLog.Success = "0";
7                    uploadLog.LogText = string.Empty;
8                    uploadLog.DeviceId = string.Empty;
9                    uploadLog.Actioned = "0";
10                   uploadLog.UserId = SessionManager.Session.UserId;
11   
12                   DateTime start1 = DateTime.Now;
13                   uploadLog.Save();
14                   DateTime finish1 = DateTime.Now;
15   
16                   TblUploadLog uploadLog2 = new TblUploadLog();
17                   uploadLog2.UploadLogId = Guid.NewGuid();
18                   uploadLog2.DateTimeStamp = DateTime.Now;
19                   uploadLog2.Success = "0";
20                   uploadLog2.LogText = string.Empty;
21                   uploadLog2.DeviceId = string.Empty;
22                   uploadLog2.Actioned = "0";
23                   uploadLog2.UserId = SessionManager.Session.UserId;
24   
25                   DateTime start2 = DateTime.Now;
26                   uploadLog2.Save();
27                   DateTime finish2 = DateTime.Now;
28   

 
Start 1>Finish 1 = 9 Seconds
Start 2>Finish 2 = 8 seconds.

I will try and get around to doing an insert directly in VistaDB to see if it's a VistaDB problem.