Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Passing Recordsets
- Thread starter glenv
- Start date
SemperFiDownUnda
Instructor
Recordsets have special marshelling coded for them. It is possible to design other object that pass well but not with VB.
Let me explain a bit more.
Normally when you pass an object what actually happens is that only the interfaces gets passed. The actual object remains where it was created.
Let us look at the following case
Machine A Creates Object B locally
Machine A is connected to Object C on Machine D
Machine A Send Object B as a parameter to Object C
ObjectC on Machine D uses Object B
Now that last step is where the big problem lies. Every time Object C uses Object B communication goes back to Machine A because that is where the actuall object exsists. And yes this is the case weither or not you use ByRef or ByVal to pass the object, I'll explain that in a bit.
Why are recordsets different? Because of the code that is used to normally pass the interfaces around. With Recordsets the actual object IS copied completely to the other machine thus it using it is all local in process calls. If you write your own object in C++ you could have them do the same type of thing if you wanted, with a fair bit of effort though.
Now what do ByRef and ByVal do if they don't make copies or send a pointer to the real object? By sending an object ByVal code is still able to alter the object's properties if the property is not an object. ByRef lets objects embedded in other objects to be replaced. So the following is possible
Machine A Creates Object B that also creates, imbedded in itself Object C
Machine A Sends Object B (ByRef) to Object D on Machine E
Object D create Object F, that supports Object C's Interface, and Sets Object B.Object C = Object F
Object B on Machine A uses Object C it is actuall Object F on Machine E
Hows that for confusing!
Hehehe in large enterprise application it could be possible to Create a Object Locally then after passing it through a few other servers to come back and actually have a handle to a remote object.
Hope I didn't confuse you to much
Short answer is that recordsets have been coded to actually pass a complete copy of themselfs across the wire where normal object stay where they are created and any access to them goes over the wire.
Let me explain a bit more.
Normally when you pass an object what actually happens is that only the interfaces gets passed. The actual object remains where it was created.
Let us look at the following case
Machine A Creates Object B locally
Machine A is connected to Object C on Machine D
Machine A Send Object B as a parameter to Object C
ObjectC on Machine D uses Object B
Now that last step is where the big problem lies. Every time Object C uses Object B communication goes back to Machine A because that is where the actuall object exsists. And yes this is the case weither or not you use ByRef or ByVal to pass the object, I'll explain that in a bit.
Why are recordsets different? Because of the code that is used to normally pass the interfaces around. With Recordsets the actual object IS copied completely to the other machine thus it using it is all local in process calls. If you write your own object in C++ you could have them do the same type of thing if you wanted, with a fair bit of effort though.
Now what do ByRef and ByVal do if they don't make copies or send a pointer to the real object? By sending an object ByVal code is still able to alter the object's properties if the property is not an object. ByRef lets objects embedded in other objects to be replaced. So the following is possible
Machine A Creates Object B that also creates, imbedded in itself Object C
Machine A Sends Object B (ByRef) to Object D on Machine E
Object D create Object F, that supports Object C's Interface, and Sets Object B.Object C = Object F
Object B on Machine A uses Object C it is actuall Object F on Machine E
Hows that for confusing!
Hehehe in large enterprise application it could be possible to Create a Object Locally then after passing it through a few other servers to come back and actually have a handle to a remote object.
Hope I didn't confuse you to much
Short answer is that recordsets have been coded to actually pass a complete copy of themselfs across the wire where normal object stay where they are created and any access to them goes over the wire.
- Status