Nerseus

First, it's probably good to start with a simple "prototype" SQL program. I'd suggest playing around with connection objects, data adapters, and such on a test app or test form to get a better understanding of the core database objects. It will save you a lot of headaches down the road and shouldn't take but a few hours. Having said that, you've got a number of problems with the code from your last post. I'll give a few suggestions here, but you should really look into getting the basics down. MS has lots of samples for making connections, filling dataset or datareaders, and updating a database. I'd start with those first and try to tweak them to your needs. After that, I'd try something more "advanced" like dynamic table creation and using the sysobjects table. Here are some things I saw in your code: 1. The SQL passed to the SqlDataAdapter needs a space between the FROM and the table name, as in: Dim da As New SqlDataAdapter("select * from " & name, connect) 2. As the error says, to use the CommandBuilder you must have a Primary Key column defined on your table. Normally this would be an INT field, probably an AutoNumber (in Access) or an Identity (in SQL Server). Since you're creating your tables manually, you'll have to add the Primary Key column if you want to use the Command Builder. You can also build your SQL by hand, assuming you know how. It shouldn't be hard since you're the one creating the table. 3. To get a list of tables in your database, you want something like this: Dim da As Nrw SqlDataAdapter("Select [Name] from sysobjects where xtype = 'U'", yhteys) In a couple of posts down, you were using: Dim da As Nrw SqlDataAdapter("Select Name from TietokantaOhjelma", yhteys) but it sounded like TietokantaOhjelma was the name of the Database. You only need to use that name in the connection string to get you to the right database (which it looked like you were, based on your ConnectionString). I'm not sure how you're creating your tables so I can't help you with how to create a Primary Key. By the way - and I should have asked this first - why are you creating tables on the fly (dynamically)? Can you not create them in the database by hand and then have your app use them? It doesn't seem unreasonable to create tables on the fly, but I'm asking because it's not done very often and maybe there's an easier or better way to do what you want. -Nerseus

If you're storing the "database" as one large XML file then yes, you'll have to read it and write it as one file - even if you only want to change one little piece. You could always break the XML files down into smaller chunks. For instance, store anyone with a last name that starts with "a" in the file "a.xml". But, it sounds like you'll be better off using a real database. Why not use something like Access, MSDE, MySQL, etc.? You've already written code to use DataSets so you're more than halfway there :) -Nerseus

Can you post the code you use to open the connection and load the data? It sounds like you've got a query that has a parameter (a "?" in Access) that isn't being set. If you have something like "SELECT * FROM Table1 WHERE ID = ?" you'll have to set the value of "?". This could also occur if you're running a Query built into Access that has a parameter defined. -Nerseus

I'm a bit confused - I don't see a Subject_ID anywhere in your picture, as a column or as a Table. Each node off the root node (NewDataSet being the root node in your case) should be a table name. From your picture, Course, Exam, Staff, and Subject are tables. Each element under those are columns. Did you mean to say that Course is showing up as a column in your Subject table and it shouldn't? I can't guess why without seeing your code but I bet it's in there somewhere :) By the way, a DataSet has a property called nested (I forget exactly where at the moment - it might be at the table level or some place else). If you set Nested to true, the XML that comes out will be nested, which may or may not be something you could use in the future. As another note, if you use the DataSet's WriteXml method in code, you can specify WriteSchema to include the table/column definitions in the XML. This would be useful to see as well, to see what the DataSet thinks the tables/columns are. If your DataSet is based off of raw XML (no table/column definitions) then the above may not work. I can't remember if the DataSet generates an inferred schema or not (assumes a schema based on the data it sees). Regardless, it would be nice to see the original XML file as well as any relevant code that creates it and/or what you're doing once you've read it in. It's also nice to know what it should be doing, as well as what's not right. -nerseus

I use this technique at work. Like anything, you may or may not do things the same way depending on your particular needs. Pure Client/Server isn't inheritantly bad, for instance, though you may believe it if you talk to some people. Anyway, we (my company) develop "components" that are hosted on a website and exposed through web services. What this means is there's a website (.NET of course) that has compiled DLLs for the components and some ASPX/ASMX pages that are basically pass-throughs to the compiled code. The webservices return XML almost exclusively. In some instances, they return or accept DataSets. The web services provide a small layer of abstraction where we can do some authentication and cacheing of often-used lookup tables. The components don't have to be hosted in the same website as the web services - heck, they don't even have to be in a web project at all. There is a separate website that handles some admin functions and reports. They're mostly ASP pages converted to .NET to help Admins who don't always work at the same machine and want/need a light interface into the system. That handles the "middle" and "data" tiers, more or less. The front end is Windows Forms. We built our own dynamic loading mechanism that downloads DLLs as needed. All forms, toolbars, and toolbar "snap-ins" (our own design) reside in DLLs. The main "app" is an MDI form and a bunch of common routines for window handling and such. Even the log-in form and authentication process is handled through a DLL that is downloaded as needed. The whole thing works rather nicely and our clients have loved it so far! The best part is the distibution/setup. The main install wizard only needs the main EXE (and the .NET framework, of course). Everything else is downloaded on demand. This is a bit different than the auto-download you may have heard of when you run an EXE from the Web. Ours uses a standard EXE setup program that creates a folder and copies our main EXE. We decided we needed a little more than what the auto-download features gave us. Anyway, to answer your original question about using data access tiers via web services, the answer is a resounding yes! :) You could just as easily substitute in a Web Form in front of the webservices layer. We chose Windows forms because of the rich controls (tabbed dialogs, grids, etc.). I've done both Web and Windows apps - windows for about 5 years, web for about 3.5 and they both have their advantages/disadvantages. Not that you asked, but since I was typing a lot anyway... :p -nerseus

It is just that, also called .NET 2003. I've read a few short pieces on it and it sounds like a slightly improved version of .NET, which sounds similar to VB5 over VB4 - not a ton of new features to the casual eye, but lots of small improvements to help professional developers. -Nerseus

Ah, works the same as VB6 then. Goooood to know. :) -Nerseus

I found this I searched MSDN for "RichTextBox code" :) -Nerseus

If I remember right, the compiled code that gets created is basically creating overloads for all of your optional arguments. You get more control with your own overloads and, I think, they're easier to use. You only have to code the overload once and hopefully you don't have TOO many optional params. If you have more than a couple of optionals you may be trying to punch too much bang for the buck into one function OR you probably end up only using 3 or 4 "versions" of the function (meaning, which params are passed and which are left "optional"). And, don't be surprised if VB.NET version 3 cuts out the optionals :) -Nerseus

First, I'm no expert on the RTB control. Knowing that, is it possible to add images to one? It sounds like you want to just append some text and/or images to a rich text box. If so (check that you can first), I'd suggest not replacing *every* occurrence of ( H ) with your own icon, but concentrate on the codes needed to get the image in there and just append the properly formatted string to the textbox. I haven't played around with the RTB in a few years but I remember that to change existing text you had to first find it, set the selection properties (start and length?) and then adjust the selected text. If you can limit your scope to just appending, it may make things a lot easier. -Nerseus

You're close, but you'll need to create an "infinite" loop to keep at least one form open at all times. Like I said, this is totally non-standard :) Here's some code to replace in your Module. NOTE: You'll have to change the project properties to use "Sub Main" as the startup (instead of a form) Changes include: 1. Create an instance of each form in Sub Main 2. Create an "infinite" loop in Sub Main. It actually runs until both forms are invisible (which occurs if you ever close one form) 3. In each of your "SwitchTo..." methods, I change .Visible=True to .Show since you may never have shown a form before. Module Module1 Dim MyF1 As ControlingASingleInstanceOfMultipleForms.Form1 Dim MyF2 As ControlingASingleInstanceOfMultipleForms.Form2 Public Sub SwitchToForm1() 'NOTE: If This Sub is decared 'Public' then it can be called from other forms and modules 'NOTE: If This Sub is decared 'Private' then it can be called ONLY from THIS form or module MyF2.Visible = False MyF1.Show() End Sub Public Sub SwitchToForm2() 'NOTE: If This Sub is decared 'Public' then it can be called from other forms and modules 'NOTE: If This Sub is decared 'Private' then it can be called ONLY from THIS form or module MyF1.Visible = False MyF2.Show() End Sub Public Sub Main() MyF1 = New ControlingASingleInstanceOfMultipleForms.Form1() MyF2 = New ControlingASingleInstanceOfMultipleForms.Form2() ' Default to showing the first form MyF1.Show() While (MyF1.Visible Or MyF2.Visible) Application.DoEvents() End While End Sub End Module -Nerseus

To add what VolteFace said (thanks, btw, didn't know VB.NET supported overloads): You can mimic your own custom optional by moving all of your "real" code into the function that takes the params. For example: Private Sub SomeFunction() Console.WriteLine("Nothing passed") SomeFunction(String.Empty) End Sub Private Sub SomeFunction(param As String) ' Can you use + in VB.NET or is that C# only? ' You might need to use & Console.WriteLine("Passed: " + param) End Sub This is handy in a lot of cases where you want to use an optional parameter but you don't want to be VB.NET specific. In the example above, the param isn't really optional, but you CAN call it as: SomeFunction() or SomeFunction("Test") -Nerseus

You're stuck updating the whole file. Unless you were to read and write the file yourself, which would get ugly fast, you'll have to work with the file as a whole. If you were to talk to a database and not an XML file (which is, essentially, your database), then the database engine would be updating those parts of the file for you. Is the XML file so large that you don't want to update it every time? Even at 10 or 20 meg, an XML file "save" should go fast. -Nerseus

Wow, do you need all those options in your Connection String? Try it with something simple like: Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program Files\Account\account.mdb The default userid for Access is Admin, so you shouldn't have to specify it. Also make sure that the database is not currently open in Access. If you database is password protected (the Admin user that is), make sure you specify the password. -ner

If I understand your question, you want to read an XML file from disk into a DataSet object, update the data then write it back out as XML? Or do you want to query the XML using XML syntax but still do everything else using a DataSet? I'm a bit confused. Assuming you've read the file in using a DataSet, you can modify the data using the DataSet or XML. You'll have to attach an XmlDataDocument object to the DataSet and then you can use standard XPath to navigate the XmlDataDocument (which will automatically update the DataSet). Saving the XML back to disk is probably easiest with the DataSet if you read it in that way. If I misunderstood, maybe you could rephrase your question or keep the typos down to 10 or so. :p -Nerseus

Is it possible to use Access's AutoNumber column type? It would work pretty much the same but you wouldn't have to run a separate query to generate the next number (which might also have issues with timing). -Nerseus

You should never design forms with anything but normal fonts on your development machine. There are known issues with using Large Fonts. For example, every time you switch to the designer the fonts will *keep* on growing and resizing. It's horrible :) If you want to code for Large Fonts, it's going to be a bit tougher. Your best bet is to get all controls setup first before you do too much coding. After you've compiled/built, switch to Large Fonts and run the EXE to see how things look and make adjustments. Microsoft has some guidelines, but a good rule of thumb is to leave a little space to the right of labels. If you don't have any wrapping captions, I've used the "AutoSize" property on labels with some success. As a note, if you have a label that may show a lot of text and you don't want wrapping to occur, you can "cheat" by changing the control to a TextBox and adjust some properties to make it look like a lable. Since the default (non-multiline) textbox control doesn't wrap, you won't have the issue of seeing the top part of a wrapped line of text. This can be useful in moderation where appropriate. To let you know how difficult Large Fonts can be, you should check out some of MS's windows dialogs. I've run into 2 or 3 that didn't work with Large Fonts - text in labels would scroll off the screen or too far down to read. Good Luck! -Nerseus

There's no longer a global variable for each form like there was in VB6 (and earlier). You can do this yourself in a couple of ways. In your Main class you can declare your two form variables and create them both, but show just one. From each form, you'd have a global reference to the other form. I wouldn't go this route, but then again, I probably wouldn't swap out forms either :) You can also accomplish the same thing by using Static methods on each form that would control creating an instance of the form if it didn't exist or returning the existing reference if it did. As for referencing controls on Form1 from Form2, simply declare the controls or variables as Public. You can do it through the designer by changing the Modifiers property or manually type it in. You could also get fancy and expose them as custom properties, to make them ReadOnly. It depends on what you're doing with them and how robust you want to be. -Nerseus

Are you saying you need to take a string and reference an existing control by name or to create a control using that name? If you want to create a control, that's easy. If you want to reference an existing control by name, it can be done but I'm not sure off-hand. Why would you need to know the control name at runtime (not design time)? Maybe there's an easier way to do what you're needing... -Nerseus

The code you have should be working. What are the columns in your table? If any are reserved words, the default "INSERT" statement will fail. For example, if you have a column named "First" instead of "FirstName" it will fail as Access uses First as a reserved word. You CAN do it, but you'll have to build your InsertCommand by hand, wrapping each column name with square brackets. For example: INSERT INTO SUPPORT ([Col1], [Col2], [First]) VALUES ( ?, ?, ?) Also, you don't need the line: MyAdapter.FillSchema(MyDataset, SchemaType.Source, "Support") When you perform .Fill(...), it will create the table for you. If you wanted only the table definition built, you could use FillSchema. You've probably noticed the performance hit when you run the MsgBox line. Once you get your tables setup correctly, it's best to copy the auto-generated SQL statements from the CommandBuilder and insert them manually into your code. That way your code doesn't have to build them every time. -Nerseus

Actually, I think you want to use sysobjects with an xtype of 'U' (for user defined). If your connection is already made to the right database, use: select [name] from sysobjects where xtype = 'U' If not, prefix the query above with "use [DatabaseName]". Make sure you have permissions (I assume you're running as sa...). If you ever need to get the columns for a table you can use the syscolumns table and join on the 'id' column from both tables. As per your original question, I'm not sure what you mean by "SQL server -> DatabaseProgram -> Tables directory". SQL Server stores its databases in files but you shouldn't care where they are, only the database name where the tables are stored. And, of course, the server name itself. -Nerseus

It sounds like you've got one of two different forms that needs to be shown based on some toggle (like a button, checkbox, etc.)? Swapping out two different forms isn't that standard - could you use a Tabbed form instead? Or possibly use two Panel controls that become Visible/Invisible based on your button/checkbox/etc.? Swapping out two forms is going to have lots of issues such as "flashing" as the forms swap, getting the positions right, keeping the forms the exact same size so as to not alert the user. It really sounds like you'd be better off with using other controls... -Nerseus

For reference, stop IIS from command line with "iisreset /stop" To restart, use "iisreset" by itself or use another switch. I would hope the install stops it, but maybe it's having troubles. As an alternative, try removing IIS through Control Panel (window options). I believe it's optional in XP. -Nerseus

Yep, you should use the BindingContext. I'd check the help as it has lots of examples. -Nerseus

You might be right, divil, but I like designing my tabs with Visual Studio. If you do all the design work by hand... well, it's tedious - unless you know another way than manually finding the right x/y coordinates for each control :) About six months ago, I played around with trying to develop TabPages through a separate .cs file (inheriting from TabControl) but could never really get anything to work well. Ideally, a TabPage would be similar to a user control or a form and they could be designed completely independently of the TabControl they were contained in. But since .NET doesn't give us that, removing them from the collection is the best bet. If you don't want to go through the trouble of creating the controls, you could design with the TabPages all added, then move out all of the code from InitializeComponent to a separate function before switching to Release mode. It's a bit more work to save a bit during runtime, but doable. - Nerseus