Nerseus

Have you seen this? I got it working in about two hours, about 1.5 of that was reading the docs and looking at a couple of samples. It should save you from having to convert all those APIs yourself. -ner

Are you assuming you've already got data in Dsspecial1? If so, you can update the first row by changing: dr = tblevents.NewRow() to dr = tblevents.Rows(0) And then change line: tblevents.Rows.Add(dr) to dr.EndEdit() If you want other rows, you'll have to let us know how you would find them in your DataSet - there are ways to search for rows, loop through rows, and more. -nerseus

Easiest way, two lines of code: WebClient client = new WebClient(); client.DownloadFile("http://www.test.com/file.mp3", "c:\\test\\file.mp3"); -ner

When someone opens the 2nd instance, are they are just opening your app generically, or are they passing the 2nd instance some params? Example 1 - passing something to 2nd instance: I open UltraEdit (a text editor) with a readme.txt file. I then go to explorer and find another text file and double click to open. I'm guessing at this part: UltraEdit opens a 2nd instance, sees that there is already one open and communicates to the 1st instance that it needs to open File X. Example 2 - nothing to pass to 2nd instance: User opens your application which makes them log in. You have their credentials stored somehow - we assume this is all working. User opens another instance of your application, or another app that needs to use your first app somehow. If there's truly nothing to pass to the 1st instance, why not just bring the first instance to the front (it's already logged in and has things "cached") and then close the newly opened 2nd instance. The user would not even know that you did this - to them, the app they wanted came up. -ner

I would think it would work if all the "Option Strict" stuff were turned off... When you pass in: New SqlParameter("@id", SqlDbType.VarChar, 25).Value = str I'm guessing that works the way it used to, which is: Creates SqlParameter object Compares the Value to str Passes the result of the comparison (or assignment, can't remember) to your function. If str is null, you might have "no problems", though you'd get some later. If that is indeed the way it's working (which would explain why "Value = 1" throws a runtime error, because it would be passing "1" to the method), then you'll need to do what IcePlug suggested. Or, as an alternative, why not enhance your method to something like: AppendParameter(ByVal parameterName As String, ByBal type As SqlDbType, ByVal size As Integer32, Value As Object) Basically, expose the params of the SqlParameter constructor as individual arguments PLUS the value. -ner

Nope, I think 130 is right. You're getting an error filling a DataSet, I assume, where the column that you're matching to is defined as a DateTime. I'm betting your DataSet is predefined (from an XSD file maybe) and the logno column is defined as DateTime. You're attempting to piece together a Number and a Date and return that as a string from the Database. So if log_no is 1 and dated is "6/30/2004" then I'd expect: 130/6/2004 The first "1" is the log_no, the "30/6/2004" is the date. I have no idea why you'd want to piece together a number and date as ONE column in your DataSet... but your DataSet better have that defined as a string column - and I'm guessing it's not. -ner

If you have a reference to the current row, you simply call dr.EndEdit(). If you're binding to a grid and the textboxes show the details for the currently selected row, then I'd use the grid to get to the right row and call EndEdit. If that won't work, you can use the Form's BindingContext property with the same datasource that you bound to: // Assume your textbox is bound with: textBox1.DataBindings.Add("Text", ds.Tables["Table1"], "FieldOne"); // Before you try to save, use this: this.BindingContext[ds.Tables["Table1"]].EndCurrentEdit(); You can optionally loop through every row of every table and call EndEdit. Generally, your bound application will know what the current row is. -nerseus

I believe you must use the number/pound sign to surround a Date in Access: SELECT * FROM Table1 WHERE DateColumn = #12/31/1999# In SQL Server you use single quotes: SELECT * FROM Table1 WHERE DateColumn = '12/31/1999' There's probably also some preferred format that Access will want - maybe "month/day/year" vs "year/month/day" etc. -ner

You might need to call the DataRow's EndEdit method to "commit" the changes to the DataSet. I believe most grids will do this automagically when you leave focus of the row or grid. -ner

Don't you expect the first program to already be logged in? And you want the second program to have the first log in as a different client? I'm trying to see what the bigger picture is (what your app is doing or providing) to see if there's an easier way to get what you want... I would guess there's a way to get the process of the first running program and maybe there's a way, via reflection, to call some code in there. If that's not available (never tried it) you could probably do it through standard Windows messages (SendMessage via PInvoke and have the first instance trapping a WndProc to receive the "raw" windows messages). -ner

The last time I remember looking into the details, if you create your connections on a server (webserver for example) using the exact same connection string, the server will automatically keep some connections "alive" for you - connection sharing on a single server. I would avoid cacheing any connections on the webserver - that's almost guaranteed to cause you grief. -ner

Which line is giving you the error? Can you step through your ASP.NET code? Trying outputting the UPDATE string with something like (right after the last set of strUpdate): Response.Write(strUpdate) Response.End -ner

Take a look at what ds.GetXml() returns - see if you can verify that the changes you expect are there. If you're updating SQL Server, try using the profiler to see what SQL string is being executed. Since you get no errors on the Update and you see changes in the DataSet, it seems like things should be working - nothing obvious comes to mind. -ner

I love watching people get fired up about things that aren't necessarily important, but still fun to have opinions about... with that in mind: Do you, or does your company, have a "standard" for using ref/ByRef vs ONLY allowing methods to return values? I've seen 3 typical scenarios: 1. [ref/ByRef is a strict no-no] A method should ONLY return a single value (the return type), ref/ByRef parameters used to return values is a no-no (maybe Ok to pass strings, for performance). If multiple returns are needed, us a custom object, hashtable, etc. 2. [ref/ByRef is perfectly acceptable] A method should return values using ref/ByRef whenever needed. 3. [ref/ByRef is mostly a no-no, but occasionally Ok] A method should almost never use ref/ByRef but it's Ok in certain, VERY limited situations. -ner PS This comes to mind as a previous boss of mine is now looking to come work for my company as an "underling". He was/is extremely opinionated and once tied up a developer meeting for *hours* trying to get everyone convinced of something that he later flip-flopped on and then flip-flopped again a few months after that.

What did you have in mind to pass? If you're just looking to display a message "You already have this app open, fool! - Mr. T", you can show the message from the second instance then have the 2nd instance show the 1st (bringing it to front) and then close down the 2nd instance. -ner PS Sorry about the Mr. T reference, I love putting Mr. T comments in a MessageBox. :)

They wouldn't really be running "from the network" - the EXE would be sent to the client machine (via the network) for running. It's a better solution to have a "loader" application that they run locally that could download the EXE (and any extra required files). We used a custom "solution" to download files, though Chris Sells wrote an interesting article I also remember reading this article a long time ago, but can't remember how much of that we used (if any). I was only involved in the beginning and ending stages of our auto-download code so I don't know all the technical details of our current solution. I know we use an XML config file on a server to tell us current versions, file dependencies, etc. (flags for "always download" and more). A coworker did all the guts of the coding - figuring out versions, downloading and installing assemblies, etc. - so I can't offer much "real" advice on how it's working. My lack of knowledge on that component also means I don't have to debug it :) Here's another article - Death of the Browser?, that describes the new way to USE the browser (or internet in general) to download "real" executables. Using a browser for an app has two main advantages: easy deployment (practically zero) and access (get to the app from any machine). Microsoft's idea was to use the browser to get a Windows EXE on the machine without the normal hassles of an installation program. I'm sure MS would be happier if people stuck with code that HAD to run on a Microsoft platform vs. a browser app that could run anywhere, but it works out well for developers who just want an easier deployment solution and don't care about the "MS is evil" arguments. -ner PS Don't overlook this article by Chris Sells. When you follow the link, check out his other articles in the MSDN Library tree on the left. Also, do a google search for "don box site:http://msdn.microsoft.com" and plan to spend a week just reading and watching MSDN TV shows :)

You can't use Cast in Access (that's SQL Server syntax). In Access you must use Format, something like: SELECT Format(log_no) + ' ' + Format(dated) AS logno FROM tblLogNumbers Your original code, using Str, should work too but you were missing a closing parenthesis. If this doesn't work in ".NET", then you'll have to show us the code you're using to call Access (DataReader, DataSet with DataAdapter, etc.). -ner

Check two things first: Look at dsClientDetails.HasChanges - if it says False then the DataAdapter won't be updating anything. If it's False, check if you have any AcceptChanges calls in your code. AcceptChanges should only be used *after* you update the database. -ner

I think we have two solutions up for proposal. You can either build a SQL string by hand (kejpa's method) or create "real" parameters (shlvy's method). Either will work, but you can't really mix and match (you can, but shouldn't). I'd use the parameters as you first tried, something like: strUpdate = "Update [tblUsers] Set [userName]=@UserName, [Password]=@Password, [RetypePassword]=@RetypePassword, [Email]=@Email, [Comments]=@Comments Where [userID]=@UserID" mdUpdate.Parameters.Add( "@UserID ", strUserID ) cmdUpdate.Parameters.Add( "@UserName ", txtUserName.Text ) cmdUpdate.Parameters.Add( "@Password ", txtPassword.Text ) cmdUpdate.Parameters.Add( "@RetypePassword ", txtRetypePassword.Text ) cmdUpdate.Parameters.Add( "@Email ", txtEmail.Text ) cmdUpdate.Parameters.Add( "@Comments ", txtComments.Text ) The only thing I really changed above was the variable names and I put brackets around the table and column names in the update string (in case any were reserved words). If you want to see kejpa's method, try this: strUpdate = "Update [tblUsers] Set " strUpdate = strUpdate & "[userName]='" & txtUserName.Text.Replace("'", "''") & "', " strUpdate = strUpdate & "[Password]='" & txtPassword.Text.Replace("'", "''") & "', " strUpdate = strUpdate & "[RetypePassword]='" & txtRetypePassword.Text.Replace("'", "''") & "', " strUpdate = strUpdate & "[Email]='" & txtEmail.Text.Replace("'", "''") & "', " strUpdate = strUpdate & "[Comments]='" & txtComments.Text.Replace("'", "''") & "' " strUpdate = strUpdate & "Where [userID]='" & strUserID.Replace("'", "''") & "'" I used the textbox's to fill in the strings "by hand". This is easier to test since you can look at strUpdate and paste that into a query window to see if it will work. The parameter objects alleviate the need to replace single quotes and do other formatting (for dates, numbers, etc.). Also, the parameters are nicer because the code is a lot easier to read: both the UPDATE statement and the named parameters. -ner

Read up on AcceptChanges, first. Basically: a DataSet keeps internal flags for each row: original, modified, new, deleted, etc. When you call AcceptChanges it clears all those flags and puts them back to "original". If you're using a DataAdapter then no rows will be marked as needing updates to the database. You didn't show your code for making the actual update (likely a DataAdapter's Update method). The proper way is to use the DataAdapter to do the Update and *then* call AcceptChanges. -ner

@VBAHole: There are many tricks to letting long running webservers let others in. We have a number of 3rd party plugins that we have to "work around" for smaller clients. Namely, reports that print on server-based printers use 3rd party controls that are NOT web friendly for the most part. Ideally we use a separate print server but smaller clients need a single web/print server and we use separate AppDomains with success. As for long wait times, the 5 seconds was extreme (I can only think of one remaining example that takes that long). It's mostly due to our many, many events that we hook and our use of a custom XML-based rules engine for data validation (more events) and databinding and 3rd party controls (custom paint events for error icons and such plus hierarchical grids)... 99% of the time a user will notice 0 delay when tabbing from field to field. Our users our *amazed* at the amount of "stuff" that we do for them behind the scenes, such as re-running fee rules and the multitude of cascades that happen as they change a single field. We use the term "cow path" to describe what 90% of the users do 80% of the time. We build special logic in those areas to make sure their experience is the fastest. The other 15-20% of the things they do they won't mind waiting for a quarter to half second to leave one field to the next. *Nothing* happens on a per-keystroke level. As some more info: I've developed many, many front-ends for users that switched to a Windows app from a mainframe app. In every case the business analysts push hard to keep the system similar to what they have, to make each user's transition a little easier. In every case, we've found that the data entry people's requirements are far different than a clerk in front of a person and the UIs need to be designed differently. For example, Data Entry clerks do not care about a drop-down that lists all 40,000 procedure codes - they LOVE typing in the full value and when they tab out seeing the description so they know they got it right. Clerks with people in front of them seem to like a more robust UI - lots of grids and sortable data and lots of linking to other parts of the system (and almost *nothing* should be modal). From that respect, our Data entry screens have been "cow pathed" to meet their needs and, from what I've heard, they've all been floored with our performance (in a good way). I can't wait til next week when we start our dedicated performance tuning! I would make one other "If I had to do it over" wish: I wish we had investigated our 3rd party control options more before we went with who we went with. In many respects our controls are "good", but they still have unresolved bugs that are *really* annoying. Some have workarounds while others are more like "sorry, but on THIS screen only, you have to click the Pay button twice". Ugh, I HATE telling a user that... I think the benefits of managed code are well worth it. If you're used to "normal" C++ (non-MFC or other "easy" frameworks) then managed will be quite rewarding. If you have a large codebase to "convert", I'd strongly suggest buying some form of training videos or CDs. We tried both (ASP.NET videos and C# CDs). The videos were a lot nicer because you could fast-forward the dorky dialog, but you need a dedicate team to actually watch them. Also, ours were video tape and so you weren't next to a computer when you watched them. The C# ones were nice, but were a LOT of reading on the computer which, unless you have a nice tablet PC, is not a fun option. Paper is still the way to go in my opinion. Ideally, pay the big $$ and have some Microsoft guys come and train a few key individuals - not on the language, which you can pick up pretty quick, but on a lot of the framework pieces. From past experience, the time spent hands-on with knowledgable MS staff is *always* worth the money. Also, pick up a few books on Patterns and Practices (if you haven't already) and investigate the MS P&P site: http://www.microsoft.com/resources/practices/default.mspx Especially: http://www.microsoft.com/resources/practices/patterns.mspx and http://www.microsoft.com/resources/practices/code.mspx -ner

If there are thousands separators or a decimal format that's not "standard" from your OS, you might need to supply a NumberFormatInfo object. Here's a sample that shows how to expand on the "CurrentInfo", determined by your machine. You can also create a NumberFormatInfo from scratch and fill in all the properties. // The following is 123456.789 in US or 123456,789 in most other countries string s = "123.456,789"; // The following will NOT work on a US system //decimal d = System.Convert.ToDecimal(s); // Specify the exact formatting you expect NumberFormatInfo i = (NumberFormatInfo)NumberFormatInfo.CurrentInfo.Clone(); i.NumberDecimalSeparator = ","; i.NumberGroupSeparator = "."; decimal d = System.Convert.ToDecimal(s, i); -ner

I believe most databases will use an index if the "LIKE" expression does not start with a wildcard. It's always up the optimizer of the DB engine for final decision though. It's generally preferrable, and quite normal, to prevent a user from doing a like search that starts with a wildcard. If you're searching a LOT of text and each piece is a large string, you might need to develop some kind of keyword indexing that exists separately from the "body" of text that you want to return. For example, a separate table that contains only keywords and another link table that links to matching records. As for showing paged results, you generally have two options: return the full dataset on every call and only display records 1 thru 10, 11 thru 20, etc. OR use some kind of persistent cursor or dataset. If this is a web app then you limit your options a bit. You might want to check out the "starter kits" available through http://www.asp.net. -ner

As a note, a little over 2 years ago my company embarked on its 2 year project (our "final QA" move is next week with a live date of Jan 2). We faced one of three options: 1. Stick with Visual Studio 6 (mostly VB6 and ASP) 2. Move to .NET WinForms 3. Move to .NET WebForms We had about 20 employees but knew we'd need to grow to about 50 before project end (we're now at about 60). Our 10 core developers (at the time) new VB, COM+ and ASP inside and out. Half the team had worked *for* Microsoft so we had a pretty good team to start with (mostly senior level developers). We did 3 months of testing in .NET WebForms and switched to .NET WinForms based on UI functionality. Aside from the typical 3rd party product hassles, the project couldn't have gone smoother! We've delivered on time and under budget and every review has been fantastic. We do have a few hundred thousand lines of code in ASP.NET as well (web services serve all the client code and web pages handle the majority of reports and some functionality for clients of our client). It did take us over a year before our "framework" was back up to speed with what we had developed in VB6 (utility functions and misc "tricks"). The tricks your team knows WILL mostly get thrown out the window if you switch to managed code but if you've got a good team and they're willing to do a lot of "catching up" to learn .NET, I think you'd do well to switch. The system we were replacing was a mainframe based client/server architecture. They got results fast, but had a lot of knowledge wrapped up only in user's brains and special "codes" that they learned over time. Our new system is *very* robust and handles about 80% of what used to be the special codes. I couldn't be happier with .NET WinForms except in ONE area: the performance of the UI code and binding is a bit slow on very large forms when you hook a lot of events. Part of our problem was our architecture of using .NET's robust event management to handle the business rules, validation, and more. What we ended up with was 4 or 5 "generic" pieces of code that would each hook events to either every control or every table in a DataSet. Anytime you change one value on the screen, a cascade of events would fire that sometimes takes as long as 5 seconds to update (in an extreme case). Personally, I hate waiting more than a quarter second when tabbing out of a field. Luckily, we've had time to do some performance testing and MS has even volunteered to let us use their test center in Texas. I doubt we'll have time to make any corrections before the Jan 2 live date, but the next project will surely benefit from the knowledge we gained. As a side note: All of our developers decided it would be best to switch from VB to C#. We made that decision for two reasons: the transition to VB.NET from VB6 seemed like more than just VB5 to VB6 (and it is!) and also, most of our developers were already very good at java and javascript so the C# syntax wasn't that new. Given the amount of sample code AND the perceived idea that MS was really pushing C# over VB.NET, it wasn't that hard of a decision. Along those lines, C# presented its own set of problems. Notably, many of the new development staff new Java but not C# (not very well anyway). Many of the Java habits didn't carryover very well and we spent an extra amount of time with each new developer to "untrain" them in the Java way of doing things (such as using == instead of .Equals). If you stick with VB.NET you'll probably have similar code reviews where one developer insists on using CType while everyone else says using System.Convert. Locations may change, developers mostly stay the same. -ner

That part is a bit confusing. To put it briefly, without thinking too much, when you declare an instance of an enum, you get a value type. That means it can be copied on assignment, it defaults to being passed by value (vs. reference), and the memory allocation is the same. As the help points out, each languague provides its own specific way of creating an "enum type", which is a value type. -ner