PlausiblyDamp

IIRC the Windows TextBox supports the .SelectAll() method while the ASP.Net version doesn't. To acheive the same end result in a web application you would need to use a client side technology like JavaScript.

Could you not remove the need for all these objects to remain in memory for so long? There has got to be a better solution than making session state persist for such inordinate lengths of time.

http://www.xtremedotnettalk.com/showthread.php?t=90608 http://www.xtremedotnettalk.com/showthread.php?t=87082 http://www.xtremedotnettalk.com/showthread.php?t=86066 http://www.xtremedotnettalk.com/showthread.php?t=84159 all cover the issue of parameters in some way.

I doubt seriously that upgrading the hardware will fix these problems, increasing the ram may delay the problem but it probably won't fix a thing. Still not entirely sure why sessions need to be kept for so long. What exactly do they mean by session in this context as I get a feeling it is different to an ASP.Net session. Could you give an example of what day to dy functionality requires server side session management for 5 hours plus.

1. Garbage collection will reclaim memory from unused (i.e. aren't referenced anymore) objects - if there is a reference somewhere (session, application, cache etc) then the garbage collection will be unable to reclaim the resources. 2. Why would they need a session that lasts 4 or 5 hours :confused: What information is being stored in a session that needs to live for 5 hours???? More importantly what is meant by and who even asked the users for their preference for server side code implementation? It might help if you gave a little more detail about the type of information being stored in Cache etc and why the need for it to be available for 5 hours at a stretch. If though through you will probably find there is an alternate solution , possible storing just IDs or similar in Session and requerying the DB when information is required. It sounds very much like a 'thick client' mentality has been applied to what is essentially a 'thin client' application. who would have though it could cause problems?

From a personal point of view I like the idea of a forum for reviews. However one initial problem is the quantity / quality of reviews to begin with. As an attempt to get something done I would suggest anyone who wishes to write a review post it in 'Random Thoughts' for now and as a short term measure they can be given a sticky to make them easier to find. If we get sufficient interest then a new forum can be created and the reviews moved to it as well as a moderation process put in place to mange it in the long term.

1. If you try to retrieve an expired item from cache it just returns null - this is something that should be handled by the application logic; I doubt 'giving up' and just telling the user they couldn't find it in cache is the correct response. 4. You get unhandled exceptions and excessive memory usage resulting in crashes :D 2. I would seriously check the running app with the CLRProfiler - although .Net memory management will free up unused objects it isn't a magic wand that prevents all memory problems. If the app is stuffing things in application variables and never deleting them memory can leak etc. In regards to the comment that could possibly reflect on the fact lots of companies have written poor quality software in .Net rather than any issues with .Net itself ;)

IIRC Transparency only works on Win2k or better - what OS is this user running? If they are running a modern OS I would recomend checking you have the latest video drivers installed.

1. I've personally no issues with keeping read only data in cache , however if the item isn't in cache that is not an excuse to give up - go reload the data into cache... however if the data being cached is excessively large (possible considering your point 2) then I would be either more selective in what I cache or more aggresive in ageing it out. 2. CLRProfiler is your friend. Use it. If you are freeing up unmananged resources correctly and not blindly stuffing anything and everything into session / application variables then you shouldn't be running out of memory. 3. Components can throw exceptions - it is a standard .Net way of signaling an error condition. Dr Watson is not an acceptable way to convey an error message under windows why should it be acceptable for a web application to die in a similar manner? At a minimum it should be directing them to a 'prettier' error screen. Deliberately throwing exceptions to crash the app is piss poor practice to say the least. 4. Nothing bad about the architecture, implementation may be another issue... 5. As a rule I am a fan of stored procs. Implemented well they work fine. 1070 may not be an excessive number although if there is a lot of redundancy then parameterising them better may be a consideration for the future. .Net will support well above 200 users without anywhere as many problems as you are getting as long as the design / code / architecture is of a reasonable standard.

When you say could you give a little more detail as to what you are expecing to happen. If you step through in the debbuger is boolFull = true?

If you do a debug build then it tells you the line number as part of the exception anyway. You can get the IDE to display the line numbers from somewhere under tools - options if you want a more visual indication of them though.

In your code you have Private Sub dlgOpen_FileOk(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles dlgOpen.FileOk Import(dlgOpen.FileName) MessageBox.Show("Bye") End Sub This will run during the Dialog's OK (Open) buttons click event. The dialog is only dismissed when this event has finished. You should really check to see if they clicked ok in your ImportGetFile routine and do the import if they did. i.e. Private Sub ImportGetFile() If dlgOpen.ShowDialog() = DialogResult.OK Then Import(dlgOpen.FileName) End If End Sub

If you have IIS configured to use Windows Authentication (and remove allow anonymous) and in your web.config have the authentication mode set to Windows then it should automatically use your Domain for authentication. If a person is logged in then no prompting should occur, if they are accessing the site from outside your domain then a login prompt should automatically be displayed. Once logged in you can check the group membership with code similar to If User.IsInRole("") Then 'Member of role End If

Could you clarify what you mean by

Any chance you could post the relevant code?

Shows up fine in my Firefox (version 1.0.5) - I'm pressuming you mean the feet along the bottom. Then again when I do a view source on the above link it doesn't contain the code you posted avove...

Does the web application require access to anything other than the files copied over? i.e. database connections, xml / xsl files that aren't present on the server? Also have you tried installing the remote debugging support on the server and attaching the debugger over the network and stepping through the code?

http://www.xtremedotnettalk.com/showthread.php?t=69043 and http://www.xtremedotnettalk.com/showthread.php?t=69690 may be worth a look

I notice you do not appear to be calling the MyThread.Start anywhere in your code - if you never start it all the code you have checking the ThreadState will never be true as it's state will always be Unstarted. As a side effect this means the .Abort will never get called either.

Not without a command object you can't - a DataAdapter can take care of the creation of the command for you but there is still a command object being created.

You can open a 2003 in 2005 and the project will be converted.

If you are using SQL you might be better off using the classes from System.Data.SqlClient rather than the OleDb ones. Also under SQL object name resolution will vary depending on who owns / created it. e.g. if it was created by a user called trend then it would need to be called like trend.Write_Logins - this is one reason most objects are created with dbo as the owner.

What database are you using? Also if you are going to the trouble of using stored procs you really should look at using parameter objects rather than string concatenation to execute them.

Arrays, ArrayList - look under System.Collections for more options

The line Dim ele As Xml.XmlNodeList = x.GetElementsByTagName("EDITME") will return a list of the elements called EDITME ele(0).Attributes("hTopColor").Value = "blah blah blah" means take the first element, ele(0), and find the Attribute called hTopColor and set it's value to the string "blah blah blah". You don't need to create a new object to assign to the attribute - just a valid string. I've updated my sample to change a button colour and also write out a modified file. The basics are there - you will just need to adapt them to your specific scenario WindowsApplication1.zip