Nerseus

Try: string s = Environment.GetFolderPath(Environment.SpecialFolder.MyComputer); string s2 = Environment.GetFolderPath(Environment.SpecialFolder.Personal); string s3 = Environment.SystemDirectory; If Environment.SystemDirectory isn't what you want, try another SpecialFolder enum value. -ner

I have the beta 1 of Team System (is that right?) at work. We're trying to find a server to put it on so we can start using it. It looks/sounds awesome! -ner

You'll want to add something like this to the where clause: AND NOT EXISTS ( SELECT * FROM tblIndividus WHERE IndividuChargéDeCompte = tblUser2.index ) -ner

In both cases you're not actually doing the Fill. After you have "daDataAdapter = new OledbDataAdapter(strSqlAbs, dbconConnection)" you need to use daDataAdapter.Fill to fill a dataset based on your SELECT (or exec of a proc, etc.). -ner

If you're just doing this for fun, I'd try C#. Otherwise, I wouldn't suggest changing languages at all. VB.NET is just as capable as C# in terms of features and ease of use (with a few, minor tradeoffs). Learning a language is only 10% of what you do as a developer. A good chunk more is learning the framework, which you've started: ADO.NET, SQL, etc. Another chunk is learning the ins and outs of a language - that will only come with really using a language for awhile. Lastly, there's the "advanced" stuff that only comes with experience: design choices. That means knowing when to use a form, a class, an interface, as well as recognizing patterns, etc. etc. If you switch languages it will be fun for awhile, but you'll only be postponing the inevitable. -nerseus

Or even have the function return the string? Module Module1 Public Sub Main() [iMPORTANT LINE OF CODE] Dim Form1 As New Form1 Form1.Text = Just_A_Function() Application.Run(Form1) End Sub Public Function Just_A_Function() As String ' Don't know the VB.NET syntax Return "Form1 Title" OR Just_A_Function = "Form1 Title" End Sub End Module -ner

If you just want to learn the language, I'd get a book and create a few small test classes to see what you can/cannot do. If you want to learn about the various pieces of the .NET framework, such as collection related classes (Hashtable, ArrayList, etc.) or DataAccess, then write some other small programs to see how they all work. DataBinding is a topic by itself, for example. Once you've gotten down the individual pieces, then think about how to put them together. It doesn't have to be a "real" application - I wouldn't code something "real" in a brand new language. You're likely to learn a lot while developing and want to re-do half of it anyway. Instead, build a program that's *meant* to be a test app from ground up. So if you want it all, then you might have a form that connects to a database, reads in records, binds to textboxes and a grid, and allows moving next/prev and updating the database. Even on a single dummy table, getting that coded from scratch will take more than a week. I wouldn't try making this an "Organize my CD collection" app, as that would overly complicate what you're trying to do: learn about the language and the framework. -ner

I can't remember the rules for distributing an Access database. You might only need to own a copy of Access (or Office, if it includes Access), or there might be other licensing restrictions. Microsoft has a free 800 number to call about licensing questions. For distributing MDAC... it used to automatically include that with a VB6 installation (the old Package and Deployment Wizard). I would guess that Visual Studio for .NET would also automatically include MDAC if it's needed. If not, simply search at microsoft.com for mdac and you'll get lots of download links. -ner

Assuming you don't want multiple machines to access the same database, I'd go with Access simply because it's easiest to setup and install on a user's machine: they'll only need the MDA components (MDAC) and the database file you provide. Access can handle multiple users at once, but it's a lot easier if you don't have to worry about. -ner

Design can take a few forms: For design of the code, I like these: Design Patterns Explained Design Patterns C# Design Patterns - knowns as the Gang of Four or "gof" For design of the system (servers and high-level programming patterns): Patterns of Enterprise Application Architecture Microsoft Patterns? Microsoft Design Patterns Microsoft Patterns and Practices The Microsoft Design Patterns link has a TON of info. Many of the documents are in PDF format, ready for printing. If you prefer a pre-printed hardcopy, they sell this series in books. This book is the same as this article. -ner

I don't know if it's a common term - just one we've used. A snapshot table is one that has pretty much NO foreign keys. It's more or less a reporting table that "flattens" out all the values. For example, you might have a customer and an order table, linked by CustomerID. In the "snapshot" table you would store both table's data in one row. We had to store the dates as varchar since the table was originally populated from converted data. The decision was made that even if the original data was bad, it was *exactly* what was printed and handed to a customer and, by law, had to be preserved. So if a date looks like "a/36/19998" then that's what we store. Obviously, a DateTime column wouldn't work here. It makes us all gumble to store things this way, but it's what we have to do - for this one table. The real point is that this almost never happens. Since you can always control the date format for reports or other UIs, there's really no reason to store a date in a particular format in the database. Separation of the data from the presentation is key... -ner

First, to do it you're going to HAVE to store them as strings (varchar) since the requirements indicate storing them in a particular format. Second, who made up this requirement? Unless it's a "snapshot" table that must store data in some exact format, this is usually the sign of a business analyst or manager that doesn't know what they're doing. As a point of reference, in my current system we have one database that has 500+ tables and only has one table that's a "snapshot" table. In the other half dozen databases used in the same project I don't think we have any snapshot tables. -ner

If you use Enterprise Manager you can add the column with "NOT NULL" and put on the default at the same time. I generally go with Plausibly's solution though, as I don't usually want the default to stay. Plus, if it's an existing table I'll need to provide a script to update the real system since the "installers" won't want to go through the GUI. -ner

Dang-nabbit. I meant McAfee for both anti-virus and firewall. I also typed costco.com but I actually went into the store to buy it (got SpySweeper for $20, too). -ner PS. I just re-read this post 3 times to make sure that it says McAfee and not Norton. My brain is fried...

LOL - you're trying to replace empty string with something? The Replace function/method is meant to replace a valid string inside of another string with something else. But you can't say "replace nothing with something". I think in your case, the most elegant solution is to just do an If. If you like readability: If e.Item.FindControl("txtForecast").Text = String.Empty Then e.Item.FindControl("txtForecast").Text = "0" End If Or if you want "performance": If e.Item.FindControl("txtForecast").Text.Lenght = 0 Then e.Item.FindControl("txtForecast").Text = "0" End If Of course, you might want to put the reference e.Item.FindControl("txtForecast") into a variable for readability. -ner

Also, make sure you mention the Database you're using as the formatting of dates is different for Access vs. SQL Server (for example). I'm glad you removed the "CONVERT" from your date column. If it were already a date, there was no need to convert it. Plus, a convert to varchar would not only be slower (the DB would have to convert every row) but the compare would be slower (string based vs. date based). The only thing I'd suggest adding is the use of ToString on the date: sqlquery = "SELECT * FROM tblBuys WHERE BuyDate= #" & Date.Today.ToString("MM/dd/yyyy") & "# ORDER BY BuyKey" -ner

Why do you need the line: myds.Tables("Staff").DefaultView.Sort = "FirstName" ? -ner

Also note that the CommandBuilder will not always build valid SQL, especially if you have any columns that are reserved words or if the table name is a reserved word. -ner

And version 8.0 was only $20 after rebate at Costco.com (in the USA), came with Norton Firewall which I haven't tried yet. -ner

They should not be boxed because the array is an int array. If you stored them in an object array then they would be. Same is true for an ArrayList, which stores objects only. I wouldn't worry too much about boxing/unboxing. True, there is a performance "hit" but I've yet to see it as an issue in any performance testing I've done. -ner

From doing a little digging, I'm guessing that your process is running as a multi-threaded apartment? Meaning, your Main has the MTAThread attribute: [MTAThread] static void Main() { ... } I believe a lack of the attribute will default to MTAThread, vs. STAThread. Here's a summary of the problem: First, if you use Process.Start("http://..."), you're basically telling it to start a process using the Shell. This means, go through the Windows shell to handle all protocol prefixes like http and open default applications for extensions. So if you tried to run Process.Start("readme.txt") it would open Notepad. You can create a ProcessStartInfo object to pass to Process.Start. If you create one, you'll see the UseShellExecute property. This is basically being set to False for you when you only pass a string to Process.Start. The problem is this: in a Mult-Threaded apartment model you cannot use the shell. Not really sure why, but it's very clear about this point in the docs :) So why not set UseShellExecute to false? You can, but then you can't give it a string like "http://...", you MUST provide a valid executable. If you want, you could read the registry and get the default browser path/filename and use that. I'm not sure where to find this, but here's a code snippet on how to use it: ProcessStartInfo info = new ProcessStartInfo(@"C:\Program Files\Internet Explorer\iexplore.exe"); info.Arguments = "http://www.google.com"; info.UseShellExecute = false; Process.Start(info); -ner

How much do you spend on the lottery? Send me half that amount and once a year I'll send you back $5. You should come out about $5 ahead that way... :) -ner

I tried your exact code to test my theory - I get a runtime error every time on either line you showed: cls.AppendParameter(New SqlParameter("@Manufacturer_ID", SqlDbType.Int).Value = 1) cls.AppendParameter(New SqlParameter("@id", SqlDbType.VarChar, 25).Value = str) I set cls = New Class1 (my test class). I defined str as a string and set it to "hello". Why not turn on Option Strict? If you do, it will catch little things like this. In general, I can't see why you'd ever want it off unless you were converting a large project and couldn't live with the compile errors... Try this test. In your class that has the AppendParameter function, define the following: Public Sub Test(ByVal s As String) Debug.WriteLine(s) End Sub Now in the calling class, try the following line instead of the AppendParameter call: Dim str As String = "hello" cls.Test(str = "howdy") What you see in the Output window may surprise you. It isn't "hello" or "howdy", it's "False". The compare is evaluated and the result is passed to the method/Sub. This isn't C++ where the results is also an expression which is passed to the Sub. At least, I've never seen any version of VB or VBET do that. -ner

When I said I spent 2 hours, I meant getting the existing Zip/Unzip code working. I wrote a quick wrapper to unzip a single file that I knew existed inside a zip file. Another wrapper would extract all files with a given extension. If I understand, you are trying to get the pre-compiled DLLs to work from within .NET? Maybe from a learning perspective it makes sense, but the link I showed gives you actual source to what the pre-compiled DLLs have. It's the equivalent of writing your own string class based on the char datatype to provide the exact same functionality that's provided in .NET's string type. If you still want help getting the API translation to work in .NET, you'll probably have to include a sample project instead of just a code snippet as debugging API code can be tricky and, I would guess, no one wants to redeclare the APIs that you've already done - especially since it appears as though something isn't quite right. -Ner

I'd start by checking out this link, which you have in the Linx section of your own website. Question to you: Are you just trying to add two columns/values to your DataSet, or are you trying to move data from one DB to another (or one table to another) and add two columns as you go? Generally, if you just want to move data from one table to another or one db to another, you don't want/need a bunch of code. Access provides linked tables - you could link to a table in another DB and write a one-shot query to insert into the other table from an existing table. SQL Server provides Data Transformation Services (DTS) to do even more. Here's the 10,000 foot view of Data Access in .NET: 1. Mostly forget what you learned in VB6. 2. Data Access in .NET falls into 3 categories (more or less): A. DataReaders - basically a cursor to read from the database B. A database-specific adapter, command object, and connection object C. The DataSet, DataView and "child" objects (DataTable, DataRow, DataColumn, etc.) The concept of a DataSet is brand new to .NET - nothing like it before in VB6. Generally you use a DataAdapter (one specific to SQL Server, OleDb or other varieties) to communicate with the DataBase. The DataSet is like an in-memory DataBase that knows NOTHING of the real database. It has it's own .NET data types, it's own version of keys and relationships, and more. Once you have a decent grasp of the DataSet and how to manipulate that, you will see that it doesn't matter if you use Access or SQL Server - the DataSet is agnostic to it all. -nerseus