Derek Stone

Dim sPath1 As String = "D:\file1.ext" Dim sPath2 As String = "D:\file2.ext" If File.Exists(sPath1) Then File.Move(sPath1, sPath2) End If

Your code should read: myproc = Process.Start("notepad") As it stands now you have no application associated with your Process object.

Strictly speaking you might want to trust just that assembly, not the entire Local Intranet zone. Of course this all depends on how much you trust your particular environment. Control Panel -> Administrative Tools -> .NET Framework Configuration -> Increase Assembly Trust

I assume you mean 150,000 K, not 150. :) This is normal behavior. I've had MSDE up to that with far fewer records, just farting around, to put it loosely. Database servers take a huge beating and it doesn't hurt to have a few gigabytes of memory. For instance, on these forums I'm fairly sure Bob has 16GB installed, and that's just the database server.

You can create a column of type "image", which can store binary data in sizes ranging from 0 bytes to 2 gigabytes. This isn't standard practice however, since it can bloat the database quite quickly. Instead, store the files in a directory.

Are you running this code against an instance of MSDE? If that is the case you need to configure MSDE for SQL authentication, not Windows NT authentication. http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q285097

No, they won't. Dim t As New Thread(AddressOf ThreadProc) t.Start() Thread.Sleep(2000) t.Abort() Private Sub ThreadProc() Try Do Trace.WriteLine("Executing...") Loop Catch e As ThreadAbortException MessageBox.Show("""Thread.Abort()"" has been called.", "") End Try End Sub

The process is quite similar to executing a SQL statement. Dim oConnection As SqlConnection = New SqlConnection() Dim oConnection As SqlCommand = New SqlCommand() Dim oDataReader As SqlDataReader oConnection.Open() oCommand.CommandType = CommandType.StoredProcedure oCommand.CommandText = "storedProcedureName" oCommand.Connection = oConnection Dim oParameter1 As SqlParameter = oCommand.Parameters.Add("@iInteger", SqlDbType.Int) oParameter1.Value = 1 oDataReader = oCommand.ExecuteReader() While (oDataReader.Read()) ' If the stored procedure does not return rows "oDataReader" is unnecessary ' and a call to "oCommand.ExecuteNonQuery()" or "oCommand.ExecuteScalar()" ' should be used instead End While oDataReader.Close() oConnection.Close()

That is how threads work-- the only way to terminate them is to throw an exception, catch it at the application level and ignore it. Calling Thread.Suspend() is essentially doing nothing, since a subsequent call to Thread.Abort() will implicitly resume the thread and then abort it.

An upgrade from Visual Studio .NET 2002 to Visual Studio .NET 2003 costs $29. I'd call that a bargain.

No, however you should close that socket prior to aborting the thread, out of courteousness to the other endpoint.

Melegant stated in his post that that code snippet works fine, since it successfully closes Excel. No advice on getting that block of code working is necessary. The second block of code is what he is requesting help with.

We can not recommend a host unless we know exactly what you are looking for. Reliability is arguably the most important requirement, however there are numerous others to consider. What do you need from the host? Also, hosting from your premises is usually a poor choice, unless you have the necessary equipment and know-how, which you outwardly admit you do not.

Take the following line for example: MyExcel.Workbooks.Open(...) Instead, call the method like so: Dim oWorkbooks As Excel.Workbooks = MyExcel.Workbooks oWorkbooks.Open(...) This coding style is required as a result of a weird inconsistency (dare I call it that?) in the garbage collector. Each COM object needs to have a managed object explicitly associated with it before one should access said object. This allows for the garbage collector to correctly free the unmanaged memory allocated to the COM object(s). [edit]You'll need to search through your code for more occurences that need fixing. I didn't bother to mention them all, if more do exist.[/edit]

Dim scr As String = "<script language='JavaScript'> document.all." & [b]Name.ClientID[/b] & ".style.left = 500 </script>"

You're declaring the Name variable inside a For/Each loop. The variable is most likely out-of-scope when the code is attempting to access it. Client IDs are automatically assigned to controls, so the possibility of it being null is slim to nill.

Dim scr As String = "<script language='JavaScript'> document.all." & Name.ClientID & ".style.left = 500 </script>"

This should be done using CSS and JavaScript. <div id="ctlFoobar" style="position: absolute; top: 100px; left: 100px;">Foobar</div> if (document.all) { //Internet Explorer or other compliant browser document.all.ctlFoobar.style.left = "0px"; } if (document.layers) { //Netscape/Mozilla or other compliant browser document.layers["ctlFoobar"].left = "0px"; }

Set the IsBackground property of each of your threads to true.

You should explicitly close them.

You could provide that level of client-side functionality, however you'd also have to support posting back to the server, since some browsers either do not support scripting or have it disabled. I wouldn't recommend an implementation such as this however, in situations where the user will be entering data.

ASP.NET's viewstate or session features can easily provide for this type of behavior. When a tab is clicked the current tab's information is posted back the server, saved in the control's viewstate and later collected and inserted into a database or other backend.

A Mutex will also work quite well in many situations.

All .NET hosts allow for managed DLLs to be uploaded and used on their servers. The usefulness of ASP.NET depends on this feature, and any host that disallows for this is either incompetent or uneducated.

The user will have to enter the path into a text control. There are no browse-for-folder controls implemented in [X]HTML.