Bummer, I have used the grid extensively to fill up with data and have the user group and sort the information. Love it for that, but this is first time trying to take a virtually empty grid and grab just the selected data from it. I've tried setting the value to <> Empty, Nothing, DBNull and many other things. Their sampls show them using a grid similarly for an odering application so I'm trying now to follow the code to see if I can locate how they check for a null value in a selected row cell. I'm also looking at how the settings for the myriad of properties may be different than the default. If any ideas pop up please let me know, Larry

lemarshall wrote: (breaking normalcy rules) These should be known as guidlines as they are subject to reality and business requirement. Having said that I alway looks very closely at a design that does not conform to these guidelines, it is usually wrong somewhere. You got it fixed - always satisfying. Never underestimate the power of human stupidity RAH

That is essentially what I already have with the exisitng tables. Of course there is a lot more information in each table, the well table contains cost center codes, subdivision, longitute and lattitude and is a many to one relationship with the Lease table. The Locations table which I switched and tried to add to the well table still has a cost center and the address of the Location I have placed in the longitude/lattitude fields with the name of the storage yard in the Well field When I had both tables no problem pulling out the well (which is actually the well number in the particular lease generally coded like: 12-34, 9-1, or 7-50- this relates to the location on a acre gridlines which each square mile of oil field leases are divided into) or the location from the location table. It always seemed to succeed when I went from well to storage or storage to well. But well to well or storage to storage I never got any data - though I have manually created the data so I know I have records for testing purposes. I was thinking I needed to add something like: w.well WHERE w.WellID = m.MovefromGUID AND w.well WHERE w.WellID = m.Move2GUID somewhere in the INNER JOIN's so I am experimenting with that right now. Any other suggestions are certainly helpfull. Some of the questions we need to ask are: What materails were moved from storage to wells What materials moved from wells to storage What crews moved the materials Total quantity of each material moved by day by week, etc. So yeah there is a lot that needs to be gathered and displayed which is why I'm beginning to question my initial database design and wondering if I need to change it dramatically now to save more headaces later. Years ago with Access 2 and then Access 2000 I finally remember doing something like what I wanted. Using the hlp for Access 2007 is nigh on useless - it is more oriented toward promoting its features than offerring help. I found an old copy of Office 2000 and installed the help and went into it for Access and what I THINK I need is some form of UNION query. That should allow me to keep the seperate tables for Wells and Locations and still be able to pull out either data in wither field. If I run into problems I'll upload a sample of the code later. Larry modified on Friday, June 25, 2010 10:07 PM

Not used Access for some years but IIRC Access will generate values for ReplicaID fields. You should only use this type if you are using replication and have the Replication Manager. As far a I remember without it replication was painful. Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis The only valid measurement of code quality: WTFs/minute.

Right, but I initially thought that I would have to cycle through EVERY textbox and if there was a value in it then store the data directly to the table then. I would be able to pick up the MaterialID from the GUID stored in the label for the row. I just thought that would be more time consuming and convoluted than this way. But I am open for suggestions. There are a lot more textboxes on the form than just the 65 for the materials so I have to be able to prevent any others from being searched. I beleive that can be done by cycling through the textboxes on tabLOLfrm.TabPage1 and tabLOLfrm.TabPage2 and tabLOLfrm.TabPage3. I beleive that the textboxes on the container are not recognized by the form so that might be one way. I remember that VB6 had the control array feature which was much easier to utilize. I have seen a number of attempts to create a control array in VB.Net but don't know exactly how to make a simple easy way to work. I've tried about 3 diferent ways from several different sources. Again, I appreciate your input and insight so far, any further assistance is greatly apreciated. I'm going to start working and this suggestion tonight and see what I can accomplish. Larry

Thanks, I seem to have that part working now. got another problwm which I don't seem to remember that in VB6. Started another post for it titled: "Lost_focus and save button"

Your problem with that is what you thought it was. frm only knows about the controls added directly to it. Containers have their own controls and the object that the container is added to knows nothing directly about it's children. You can access it through Me.TabPage1 because it's a variable that was declared within the form, but it was never added to the forms control collection, it was added to the tabControl's control collection. If you want to be able to search through children controls as well, you could do that using a modified version of what I posted earlier. Public Shared Function getControlArray(ByVal baseControl As Control, _ ByVal controlName As String, _ ByVal TypeToReturn As Type, _ Optional ByVal separator As String = "") As Control() Dim aList As New ArrayList For Each ctrl As Control In baseControl.Controls If ctrl.Controls.Count > 0 Then For Each item As Control In getControlArray(ctrl, controlName, TypeToReturn, separator) aList.Add(item) Next End If If ctrl.Name.ToLower.StartsWith(controlName.ToLower & separator) And \_ ctrl.GetType = TypeToReturn Then aList.Add(ctrl) End If Next Return aList.ToArray(TypeToReturn) End Function I just made the Form being passed in a Control instead and check that control for any children, then it recursively checks the children. I tested it by adding a TabControl and several Labels to a TabPage and it works as expected. You can also just pass in the TabPage if you know that the items will only be on that TabPage.