So.. What I "think" I am understanding is that in the following dummy code, the "actions" relating to SPT only execute against the Table and Point ID that has Focus. The reason for this is because the gINTRules.Grid data only returns a recordset of the Focused Current Boring, Focused Table and Grid Data of that Focused Boring and Table. (Is this statement about what the gINTRules.GRid returns correct??)If I want to perform acts on ALL the Borings (PointID's), then I need to create a Dynaset having the PointID's and work on THAT Dynaset recordset, right?
Am I on the right track in my thinking about the 2 types of recordsets?
Bottom line (besides my gaining understanding of things) is that I want to do the same SPT acts on ALL the Borings, not just the one focused in the top dropdown.
Public Sub Do Great Things ()
'Dims in here
iPsDepth = .FieldCol("Depth")
iPSBlowType = .FieldCol("Blow Type")
iPSBlows1 = .FieldCol("Blows 1st")
iPsBlowDist1 = .FieldCol("Penetration 1st")
iPsBlows2 = .FieldCol("Blows 2nd")
iPsBlowDist2 = .FieldCol("Penetration 2nd")
iPsBlows3 = .FieldCol("Blows 3rd")
iPsBlowDist3 = .FieldCol("Penetration 3rd")
iPsASTM_Style_N_Value = .FieldCol("ASTM Style N Value")
iPsxGEL_SPT_String = .FieldCol("xGEL SPT String")
For lRow = 1 To glNumRows
'Do some stuff there relating to SPT
Your thoughts in text are generally correct, but the code has many problems. Also note, the table event you should us for this is After Save.
You need to loop through the record set, it is not related to GridData. A quick google returned https://docs.microsoft.com/en-us/office/vba/access/concepts/data-access-objects/move-through-a-dao-recordset
Phil WadeDatgelBentley Channel Partner and Developer PartnerE: firstname.lastname@example.org | T: +61 2 8202 8600 & +65 6631 9780
Get the most out of gINT with Datgel Tools.
I think that what you are saying is to dispense the GintRules.GridData and create my own recordset appropriate to what I am trying to do? Certainly in this case to write my own, but is it just better to dispense with it all together and write my own SQL's and make my own DB Connections instead of using the gINTRules Object.
That I can do as I do it all the time in other apps connecting to a database..
As far as the code having "many problems" ... your are meaning that the GintRules.GridData has limitations ( for example , returning a recordset having the Focused Boring's current grid's data) , and problems arise because of limitations like that, right??
When I first came across the GintRules.GridData in the code samples and the Manual, I went HUH?? Well, OK, it must be something very special, and Ill go with it as part of getting a handle on how gINT does things. I saw GintRules.GridData used "all over the place" and I just followed along.
As far as creating and looping thru a recordset, I do it all the time (in other coding projects) I thought the GintRules.GridData would include all the PointID's, but apparently not, and I can only loop on the current boring that has focus.
(LOL - I see that the name itself more than implies that it is a recordset ONLY for the focused boring's data that is in the grid the user is looking at, and that my mentalmodel of what it was, was off base.)
You should use the gINT Rules current project object, rather than making another connection. You don't close the gINT current project connection.
Your code example was setting iPs variables and looping through an array, this is not relevant. You make a recordset based on an SQL statement, and loop through that, reading and/or editing data. Your SQL statement could be for the same data as on current grid, or what ever you want in the database.