PlausiblyDamp

MainForm s = new MainForm(); is creating a new instance of the MainForm, not refering to the existing one. This is probably worth a read.

You probably want to take a look at delegates, these are similar in concept to a function pointer but are typesafe. A delegate can contain a list of functions, effectively acting as an array - when the delegate is invoked each function in the list will be invoked.

MSDE is not designed for that size of data or that number of users, if you require those kinds of figures then you would need to upgrade to SQL Server.

With the line Form1 obj = new Form1(); you are creating a new instance of form1 not refering to the existing one. this is probably worth a read.

Something like Dim conn As New SqlClient.SqlConnection("Data Source=localhost;Initial Catalog=master;Integrated Security=true") Dim cmd As New SqlClient.SqlCommand("DBCC Shrinkdatabase (Northwind)", conn) Try conn.Open() cmd.ExecuteNonQuery() Catch ex As SqlClient.SqlException 'handle error here MessageBox.Show(ex.Message) Finally conn.Close() End Try should do the trick. Also if you are using SQL 2000 (not sure about 7) you need to use shrinkdatabase not shrinkdb like I said earlier ;)

It may be possible to convert it to VB using one of the many free C# -> Vb convertors found on the internet, or alternatively you could just compile the C# class(es) into a DLL and use the DLL from your VB code.

What do you mean by ? If you simply want to remove freespace then look at the DBCC ShrinkDB command, if you wish to check for potential errors in the db structures then something like DBCC checkdb may be more useful.

Could you not just handle the exception and either wait a while or prompt the user to try again?

that is the fundamental design of .Net. Try running the exact same compiled application on another PC with a different work load, more or less physical memory, more or less available memory and see if the results come out the same. Running on the PC in from of me I only have 256M and I am not getting a drop in the memory reported to be in use even after the GC.Collect call.... Tracing through the app with the CLR profiler though does show the array being allocated on the heap, a consistent memory usage for the duration of the button click, pretty well independant of what taskmanager is reporting.

Could you give a hint as to what the problem is (or at least where it seems to be happening).

any chance you could post a bit of the code you are using?

Button2_click would be a valid event handler for a button click event, really just a subroutine with a specific method signature. 'should be similar to private sub Button2_click(sender as object, e as Eventargs) 'handle button click here end sub

If you check the link in the sticky at the top of this forum it gives you the solution to this problem.

Check the line Dim textDwg As TextBox = e.Item.Cells(3).FindControl("txtDwg") and see if it is returning anything,

The task manager will match, both show you the physical memory allocated to your process. However .Net will not always release unused memory unless the OS requires it; so you can see large amounts of ram allocated without it meaning anything in regards to the current usage. For example where you have oMemUsed.Report() ' <-- Reports 0 try putting 2 calls to oMemUsed.Report() and see what the result is. I get values similar to (but not consistent with) oMemUsed.Report() ' <-- Reports 0 oMemUsed.Report() ' <-- Reports 700,416 try with 3 calls or 4 calls etc - as you can see the results really are not indicative of any actual change as a direct result of any allocations....

Which line actually generates the error?

What kind of allocation are you getting before you declare the array and secondly after you declare it but before you start to fill it? Also Environment.WorkingSet is just a record of the memory mapped to your process - this does not give you any idea how this memory is being used or what effect GC is having on this utilisation. If you are trying to track memory / GC in any kind of useful way then you want to investigate tools like the process monitior from http://www.sysinternals.com or CLR Profiler.

You could serialze the array into a blob field, or possibly turn it into a delimited string and store that. Is there a reason you need to fit this into a single field? Could you not store the elements within a seperate table and use a PK/ FK relationship to associate them with the parent record? Without a bit more detail on the size of the array and the strings it contains and the possible contents it is a bit difficult to say what method may be best.

If you are spawning multiple threads then you should see them in taskmanager - unless they are very shortlived. Without seeing any code though it is impossible to say exactly what is going on though...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-rm.asp

Have you considered storing each of these items within a class (just as member variable or properties) and using .Net's serialisation routines to persist the class to disk?

The problem with that scenario is that users now have to remember 2 user name / password combinations (one for the domain, one for the application) and keep them in sync when one or other forces a change. Also if Molly is using the system she would still have to at least close the application and re-run it to logon as herself anyway... This also imposes another security weaknes as now there is a second copy of username / password pairs to be maintained, stored, backed up etc. If this second copy is stored using a weaker form of hashing or encryption or stored in a less secure area (including backups) than the domain then this becomes a simpler target for would be hackers. If a person is using the PC they should be logged in as themselves so auditing etc can easily be done, if this can be integrated within your application all the better. When finished logout and others can use the PC.

At the very least you could get rid of the ToString and the associated string comparison by doing if(a is System.Windows.Forms.TextBox) { b = a.Text; } for the check

In the setup project check the properties for the file in question and see if the Vital property is true - if so try setting it to false and see if that makes a difference.

The intellisense and the background compiler are improved in the 2005 version, errors are displayed similar to in VB now.