PlausiblyDamp

One thing to try - if you open the assembly with ildasm and look at the manifest there should be entries that begin .mresource public try using the exact same string as is listed in the manifest and see if that works.

You might find it easier to download the data in question as a stream (using the .OpenRead method) - this will allow you do download it in chunks and do any relevant status updates in between chunks.

If you do not catch the exception what does it say on the error dialog? Or if you put a breakpoint on the catch block what type does the debugger say ex is?

IIRC Access doesn't support the INHERITS keyword when creating a table.

http://www.xtremedotnettalk.com/showthread.php?t=93547

What database are you using?

It might be better to rethink your approach, if the string is part of the form then why would the other classes need access to it? It might help if you gave a little more detail about why you need this as there may be an alternate solution.

What error does it give? Also try the following Dim cmdstr As String = "" Dim rdstr As String = "" rdstr = "SELECT store FROM stores" con1.Open() con2.Open() Dim cmdread As New OleDbCommand(rdstr, con2) Dim objreader As OleDbDataReader = cmdread.ExecuteReader() Dim cmdmke As OleDbCommand Do While objreader.Read() objreader.Read() cmdstr = "CREATE TABLE [" + objreader("store") + "] INHERITS [store sample]" cmdmke = New OleDbCommand(cmdstr, con1) Label1.Text = objreader("store") cmdmke.ExecuteNonQuery() <<<<<<<<<<< ERROR!!! Loop con1.Close() con2.Close()

You could declare the methods / properties as static ( C# 2.0 the class itself could be declared static) - this would result in only a single instance being allocated in memory.

It really depends on the page layout - if the page has a tabular design then a tbale is fine. If the page has a more fluid layout and you find the structure is getting far too complex then s are a definate possibility. Depending on how you are doing the rendering to html http://www.asp.net/cssadapters/Default.aspx may be worth a read.

If you are using a DataSet then you can add a DataRelation to it via the DataSet's Relations property - this will allow you to programatically navigate the relationship. If you have the .xsd that defines the schema then you can add this to your .Net project and VS will build a code model around the schema for you.

In terms of the case sensitivity it might be easiest to create a class that inherits from Hashtable and override the relevant Methods (Add, Remover, etc.) and simply upper or lower case the string used as a key value to prevent case being an issue. The order of returned elements is a more fundamental issue and relates to the internal storage mechanism use by hashtables - solving this wouldn't be trivial. If this is a real problem you might want to look at creating your own custom collection class.

IIRC Winfax.dll isn't a .Net / COM component - you would need to access it through P/Invoke rather than by adding a reference. There is also a FaxCom.Dll that can be added as a reference - that might be of some use.

If you cannot rely on the page being posted back then your solution is probably the best. If someone is using some form of pop-up / cookie blocker then there is nothing you can do except 'educate' them to either allow cookies from your app or just live with the problem.

In that case check if either of them is nothing and drop a debug message to the page telling you if either of them is nothing.

If you put a breakpoint on that line and run the code what value does the debugger display for objDS and grdRecs?

Where do you keep getting the error?

The AppDomain.CurrentDomain.UnhandledException event is probably what you are after then.

Something like private void Page_Load(object sender, EventArgs e) { NorthWindWS.Products objWS = new NorthWindWS.Products(); try { if (!Page.IsPostBack) objWS.BeginRetrieveAllProducts(new AsyncCallback(RetrieveData_CallBack), objWS); else { lblError.Visible = False; lblError.Text = String.Empty; } } catch (Exception exception) { lblError.Visible = true; lblError.Text = ex.ToString(); } } private void RetrieveData_CallBack(IAsyncResult ar) { DataSet dsTemp = new DataSet(); NorthWindWS.Products ws = (NorthWindWS.Products)ar.AsyncState; dsTemp = ws.EndRetrieveAllProducts(ar); dgProducts.DataSource = dsTemp.Tables(0); dgProducts.DataBind(); } should do the trick.

In the constructor of the derived class you could be calling functionality or accessing members declared in the base class(es), the base constructors need to be run before any code in the derived class' constructor to ensure that this underlying code is in a consistent and initalised state. If you are doing lots of complex work then perhaps a constructor isn't the best choice and you might need to consider an alternative method.

What is your application doing? What kind of resources is it allocating? GC.Collect will only free up unused resources - if you still have a reference to a variable then GC.Collect will not be able to reclaim the memory.

If you are in the IDE you can use CTRL+F5 to run without attaching a debugger. If you are hitting exceptions in debug mode then that means a release build will crash - you should be dealing with the exceptions in a try ... catch block.

You could potentially do this using a cursor, this would allow you to step forwards or backwards through the data in a table. Is there a reason you need to get each record individually though as this is often not the most optimal way to access information a SQL (or any client / server db).

Exceptions are the .Net way of raising / handling errors. To handle an exception you would use a Try ... Catch ... Finally block. If you need to signal your own error conditions then you use the throw keyword to raise a new exception. e.g. Public Sub Test(ByVal name As String) If name Is Nothing OrElse name = String.Empty Then 'check name is valid Throw New ArgumentException("You must provide a valid name", "name") 'if not raise our exception End If 'more code here End Sub

Since I started using Unit Tests the amount of problems that no longer appear when 'revising' old code - run tests and all pass, make the changes, run tests again. If everything lights up green then you haven't introduced any new bugs by tidying up old code. It gives an enourmous amount of confidence when attempting to refactor old code to be able to check that nothing has been broken. Additionally bug fixing is easier when you write a test that demonstrates the failure - once the bug is fixed the test is green (as are all the others) therefore job is done.