quwiltw

Right-Click on DataConnections and choose "Create New Sql Server Database" in the server explorer.

I think you mean that the Jet data engine, the default underneath Access won't be supported in the near future rather than Access -- which will in all likelihood be supported indefinitely? I suspect that MSDE will sometime soon replace Jet as the default data engine under Access. Btw. I agree with Derek (other than the above). If there's a chance you will get more than one user or will ever want to scale up - then MSDE is the answer. Since MSDE is itself based on SQL Server, when/if you outgrow it all stored procs, views, etc. will work no problem meaning there's clear and clean scaling as opposed to Jet which doesn't present an easy scaling solution to full blown SQL Server.

Access will make use of indices as it can. You don't explicitly reference them in queries.

Someone may come along with a better answer but this appears to work. The version number returned appears to be just the major rev not the full version number (which I was unable to find in the registry but you may want to look around more) Private Function IsVisioInstalled() As Boolean Dim strKey As String = "SOFTWARE\Microsoft\Visio" Dim r As RegistryKey = Registry.LocalMachine Dim rSub As RegistryKey = r.OpenSubKey(strKey) If rSub Is Nothing Then Return False Else MessageBox.Show(rSub.GetValue("CurrentlyRegisteredVersion").ToString) Return True End If End Function

Yeah, maybe by using "grab" I made it sound a bit easier than it is. Any 2nd year CS textbook will describe them. You can search the web but I doubt you'll find in a single place what the pros/cons of each are (ie. some are optimized for searching others for insertion, etc).

"Now heres the trick." I don't understand the trick or exactly what you're asking. Maybe a sampling of data would help us understand.

I would hesitate to call a tree a "really complicated data structure" and would think that you'd be better off keeping with your tree than a dataset if your main concern is performance. Now I've never had performance issues with a Dataset but in my apps so far no significant wait == no performance problems. But if my primary concern was performance, and not deadline, then I'd go with a custom data structure made specifically for the job. Instead of doing your own have you considered just grabbing one of the various well-documented Tree structures (AVL, BTree, BST, Red-Black, etc.) and porting it to VB.NET?

I'm not sure what Ariez is referring to but there is not Distinct keyword that can be applied to the dataview. To my knowledge you'll have to build it yourself. One way would be to loop through the table adding unique ID's to a comma delimited list, then using the IN keyword on the dataview's rowfilter.

FillSchema doesn't "read" all the data in the table it just gets the structure.

Perhaps you could create a temporary dataset then use the DataAdapter's FillSchema() method then traverse the schema to determine what the primary key is which FillSchema should have been able to determine. To keep it independent, I assume you already have some sort of factory class that return instances and you are only dealing with interfaces? If so just change the interface to DbDataAdapter (which provides FillSchema) which all of the big adapters inherit and should keep you neutral.

Are you asking about the volume serial number of the disk? I'm not sure what you mean by Serial Number.

How so? I think you should have no problem finding a 3rd party charting vendor that has a royalty free distribution licensing structure. They wouldn't sell much if it were all on a per-seat basis.

My first thought is to loop through the rows of dataset2 and add there ID's to a comma-delimited list. You could then use the RowFilter on DataSet1 along with the "IN" operator to filter down to either the rows you want to delete or negate it and get the rows you want to keep. If you use a StringBuilder the first part should be quick, but I have been unable to really determine just how quick applying rowfilters are thus far. Note: Just to clarify, I'm following your lead and using the term Dataset loosely. I assume the context will tell you above whether I'm talking DataTable or DataView.

i don't understand your question

This should help you... http://www.xtremedotnettalk.com/showthread.php?s=&threadid=71245&highlight=Mutex

Just to put my 2 cents, I think this is a key point. I think with a Bachelors degree, you've got a better chance of getting a cold interview. If you have other ways of getting into the interview other than mass-mailing the resume, then you're probably on equal footing with anyone else applying. If a person makes it to my office for an interview, I ask the same questions whether they have a degree or not and by the end of the interview the only thing I really care about is whether I believe they know what they're talking about or not. Having said that, my boss is more concerned with what there bill rate will be so he has different motivations that have less to do with true knowledge.

I like it for the one time code-generation after the initial design phase. Having said that, if I didn't get it for free, I wouldn't be willing to pay for it. If I could buy a UML tool I'd get Rational's XDE which support round-trip engineering and side-by-side model/code view. It looks sweet, but unfortunately I'm stuck with my free Visio.

System.DBNull.Value

Not a "true" typed as in backed by a schema, but custom datasets that are typed through custom buildtable routines called in the constructor - Duwamish-like. It's been a while since we made the decision but it was something about the regular typed-datasets declaring columns or something as friends so they're unavailable outside of that particular assembly. Since we're defining our datasets as the common data structures between tiers in their own assembly, that didn't work so well.

I have the EA edition so I don't know, but you could probably find out by starting a new UML drawing then see if you have the following menu entry: UML->Code->Generate...

If you've decided to go the Business entity route, then you should probably remain consistent. With ADO.NET, I'm frankly seeing little need for true business objects and instead using pseudo-typed DataTables as containers. We're using a BusinessRules layer that provides validation on saves and such. We basically went with a Duwamish-like architecture.

In that case it sounds like you'd want to inherit from CollectionBase and override Item, Add, Remove, etc. to accept your business entities. Unfortunately Visio's support for working with framework classes is poor so you'll have to work to get the generated code correct with this. When the code is generated the name becomes the variable name inside the composite class.

In Visio at least, it really depends on what type of relationship you create between them and it's definitely not for visual purposes only. You'll probably find yourself creating Composition and Generalization relationships most often. Composition is when you want one class to be composed of another (ie. contain a variable of that type inside it) while Generalization is another way to say inheritance. As far as being easier to code by hand, I couldn't imagine that being true for any reasonably complex piece of software. We document our design in Visio, then do a one-time code generation after the initial design phase which gives us well-commented stubs for all classes. It makes it really easy to point a developer to a commented stubbed out class to implement.

hog, you might want to check out some of the articles here: http://www.windowsforms.net/Default.aspx?tabindex=3&tabid=40#Deployment Looks like there are several solutions that already do what you want. The "Updater Component" article looks very much like what you're describing.

Check out [msdn]System.Threading.Mutex[/msdn]. Which will allow you to do something like this, which prevents any renaming workarounds. Dim objLock As New System.Threading.Mutex(False, "MyAppLock") Dim blnIsRunning As Boolean = Not mtxLock.WaitOne(0, False)