Thanks J. The more people comment here, the more confortable I feel about our current approach. Albeit not perfect, I'm pretty sure we're in the right direction. And yes, we're upping the Unit Tests lately, which I've banged on about loads, and 'time' is finally being properly allocated to it from the 'time' people.... Thanks J

Well, yes we do already use the tables from a web service as well as the website itself, using the same DAL DLLs that throw up any exception to the calling service, which handles the failure accordingly. We are in control of all this and any furture development. Thinking about, I think I need to double check the SQL transactions we are using, which aren't many, for their return status and how we're handling those, and I'm just writing a function to check the record count from an update/insert or delete, so that that can be handled at code level. Thanks Eddy for sparking some thoughts in my head...

Thanks Richard. Glad you agree. We have kept the Stored Procedures fairly straightfoward, so no worries on the tidy up front. Wil certainly take that on board for future development though. Thanks. Julian

Yes, that did cross my mind. Fortunately, I don't think that's ever going to happen.

Hi. A general question I wanted to ask someone. Thought here would be a good place. For Stored Procedures (SP's) in a SQL Server Database would you consider it acceptable to leave any error handling to the calling code (i.e. caught in an exception handler in the .Net code), and just check the number of records affected in the .Net code too, for extra validation. Rather than, handling errors in the SP's and returning a value indicating things like no. of records affected and whether an error occurred whilst trying to execute the procedure. I'd like to keep the SP's as simple as possible, and handle problems at the code end as it seems easier to do that. But not sure if we're missing a trick with any error handling by the SP's? Hope I've made myself clear. Thoughts? Thanks J

What are people's preferences for using numbers or letters for a field that indicates the status of something? If something is 'In Progress' you might use the letter 'I' in a Char field or a 1 in a number field for instance. As soon as the record is 'Complete' it get updated to a 'C' or a 2 for instance. My preference is number, so that they can easily be turned into an enum at the code end. It causes arguments at work like you wouldn't believe....! Anyone care to make a view? Julian

Very funny.... :laugh: And I meant Wednesday in my post not Tuesday BTW. J

Well, we had a funny that took up most of Tuesday. Any .Net DateTimePickers in a WinForm that had a custom date format that didn't show the day (e.g. just showing Month and Year - 'MM yyyy') caused an exception on trying to change the year. Internally, the control didn't change the day when changing the year from 2012 to 2011, causing a date of 29/02/2011. The DTP threw an exception. This affected 17 forms in 1 program. To get round it, on loading the form I made sure that the date was formatted to 01/ + whatever the current month and year are. :( Julian

I don't know what I haven't told you .... yet.... :)

OK, have now got this sorted. Previously the .exe I was doing performance enhancements on was 450Mb in size and took 1m30s to load each form it needed to create (from within the app itself)! I managed to get this down to 1m15s on the first time the form was opened and 10 seconds every subsequent time it was opened from within the app. Memory usage was down to 150Mb. I was quite pleased with myself. The target application server is 64bit. Setting the target CPU in the project settings of the application to x86 from x64 brought the size of the .exe down to around 60Mb and there is no delay on the initial creation of the first form from within the app. Knew I'd get there in the end. Thanks for all your input into this guys. Some most interesting suggestions. Cheers Julian

Um... thanks for that Eddy, but what if your Dialog requires lots of controls? J

Thanks for your input charliezcr. I don't have a problem with the queries. I'm logging all the queries I'm doing and can see how long each one takes. they are all normal. I am exploring other avenues at the moment whilst looking at another part of the code, so don't worry. Thanks Julian

Phew, thanks Pete, thought I was missing something there.... :)

Thanks Luc. I'll give that a go myself but spark off the form from another form, and try it a second time and see if it takes just as long on the second time. Interesting. Cheers Julian

Thanks Dave. I am indeed populating many DataGridViews, which at this point should have been loaded with their data. Not hundreds of rows per DGV tho. I'll bear it in mind. Cheers Julian

Thanks Luc, You've helped me identify some places to look and I shall double check the Form Show event. Don't think that the database has anything to do with it, we issue a query and it comes back, (some take longer than others) but I've never experienced a query to the DB causing a hang of sorts after it has returned. That's not to say it isn't a first. The DB as I say is old and the interface to it seems to be not overly supported. Thinking about it, that is an area i haven't looked into. Time to investigate the Alpha logs.. oh no... save me.... Cheers Julian

Thanks Pete, that's a good idea, I'll see what I can do. Cheers Julian

Hi Luc Thanks. Yes I agree, 30 seconds is totally unacceptable! And strange. I'm trying to find out what's causing it now. On the face of it, the program is not doing anything! But I do see the server memory going up and up during that 30 seconds. The database connection thing has been the way the company does things for along time. I've tried a separate app that does indeed do what you're suggesting (putting queries in threads etc.), but somehow, the Alpha database (it came out of the Ark) can't handle queries being done on threads other than the main thread. So, I've stuck with one connection. I'm pretty sure there's no threading issue during that 30 seconds, but it's something i will check. Thanks again for your response. Julian

Hi The connection to the database is active before the form loads, and is not dropped for the duration of the application lifetime (it's a secure self contained network). The database as stated is an Alpha database running on a VMS server. We have a windows dll interface to it. I'm interested in your point about .Net not releasing memory. If I create a new Form each time (Form1 creating Form2 - Form2 being the Form in question), do you think that .Net will intelligently store stuff it needs and call on it again when I create a new Form2? Thanks for your response Julian

Hi Yep, already logging like crazy. I have 2 logs on the go, Log1: almost every function logs it's 'In' and 'Out' times in milliseconds Log2: Every single query performed on the database is logged to a separate file and time stamped. I can see from the combination of these what takes time. So I can see for instance that the Form Shown event finishes at time x (on first showing), and the form doesn't actually appear on the screen until 30 seconds later. Also, no queries occur or other functions called during that 30 seconds. The database connection (as stated, an Alpha database running on a VMS server) is never dropped, it is continually open and open before the form is first constructed. Untangling the data from the tabs would be too time consuming (showing data as needed), and we would be issuing queries multiple times, when it would only need to be once at the beginning. However I have taken this approach with the second tab control (there are 2 on the form - 1 with 1 image per tab, and 1 with controls on each tab). The image tab control does indeed load it's image only when necessary as image handling can take time. I think it's too late to re-show the dialog and simply re-populate the controls on showing the second time, and the second time isn't a problem anyway. I'm also using threads to help populate the form, attempting as best as possible to do many things at one time. So, still not sure. Julian