The information in this article applies to:
SUMMARYThis article describes how to build, debug, and validate a custom business object for use with the Remote Data Service (RDS). The sample code is written in Visual Basic, however, the techniques demonstrated are valid regardless of the actual language you use to implement the business object (if the language can generate an ActiveX DLL). MORE INFORMATIONThe RDSServer.DataFactory business object provided by RDS has four methods. However, two are typically found in any given business object: the Query method, which returns a recordset, and the SubmitChanges method, which processes and attempts to post any changes made to that recordset. Your business object will likely need the equivalent of these two methods. In addition, two others will be handy for validating both the functionality and installation of your custom business object. Method 1 - SumInt()SumInt() tests if the Business Object can be created.This is a simple method that returns the sum of two integers you provide as arguments. You would use this method to confirm that the business object can be created correctly from either the local or the remote client. If it fails, then either the business object is not correctly registered through Regsvr32.exe, or additional "safe for..." registry entries may be required on the server or the client.
Possible causes for failure could include the following:
Method 2 - ReturnRSValue()ReturnRSValue() tests if the Recordset can be opened.This method verifies that the connection and query information you are providing to the business object is correct. It will open but not return an ADO Recordset. It does return an array of variants for the first record in the recordset obtained by the GetRows method. If this is successful, then you know the Recordset you are requesting can be created on the server, which helps isolate any difficulty from an inability to receive it on the client. Following is some sample code for the ReturnRSValue method:
Possible causes of failure could include the following:
Method 3 - ReturnRS()ReturnRS() tests if a Recordset can be returned.This method returns the recordset that ReturnRSValue() opened. This is actually an archetype method for a business object, and equivalent to the RDSServer.DataFactory's Query() method. However, because you are implementing this method yourself, you can take advantage of the full ADO Object model, such as using the Command object to open a parameterized stored procedure. The DataFactory would not be able to do this as it just creates a standalone Recordset object. However, you should open the exact same kind of recordset in ReturnRSValue() as ReturnRS(). Following is some sample code for this method:
Method 4 - EnhancedSubmit()EnhancedSubmit() sends changes back to the DataStore.This method accepts a recordset and uses it to re-open a connection to the underlying DataStore and submit, in batch, any of the changes you may have made to that recordset. For any records that were not posted to the DataStore, it provides details indicating why the failure may have occurred. It also returns a second recordset that contains just the records that failed to be posted to the DataStore. This is actually an archetype method for a business object, and is a superset of the functionality found in the SubmitChanges() method of the RDS.DataControl and RDSServer.DataFactory. Note that the method checks for the occurrence of error 3617, an undocumented RDS error. This may, depending upon the development environment you use, come back as either 0x80040E21 or -2147217887. Following is some sample code for this method:
The CheckStatus subroutine mentioned in the preceding code above is provided in the RDS series of samples listed in the references section and builds a string based on the flags that are set in the Recordset.Status property. You can use this to see why a given record failed. A variation on this conflict resolution code is provided in the RDS* series of samples, as well as the RDSENSUB sample also listed below.
General Diagnosis and Debugging TipsUsing a Local ClientWhen you write your client, you will not be able to step into the business object if RDS is used over HTTP to invoke it. You should consider the advantages of writing a local client which just instantiates the business object independent of RDS. This is easily done for Visual Basic for Applications, C++, or Java; however, if you are using VBScript, you should consider writing a Visual Basic Local Client to get the same effect.This lets you validate the functionality of your business object, and debug any issues that might be there. Especially for Visual Basic-based business objects, as the compilation doesn't always catch syntax errors that the more rigorous C++ or Java Compilers would prevent. Whatever methods the remote client using RDS invokes, you should also invoke with your local client to ensure the validation of the code within the business object. However, there will be some differences in behavior with a local client. For example, the recordset MarshalOptions property will have no effect in a local client. Consider this code:
This tells RDS to submit records only to the business object (custom or
default) that are changed or added (and of course indicate any deletions
that may have occurred). With your local client, as you are bypassing RDS,
there is no marshalling; therefore, this property has no affect. The entire
recordset is passed to the business object, not just the modified records.
The Joy of ClsidViewThe CLSIDView utility is an ideal mechanism for verifying the registration of your RDS Server or Client components.The CLSIDView utility is available for download from the Microsoft Software Library. For download information, please see the following article in the Microsoft Knowledge Base: Q176562 FILE: Clsidvw.exe: OLE/Createable Objects Registry DiagnosticClSIDViews can also be used to manage the registration of your business object. Once you have registered it with Regsvr32.dll, in the Find combo box, type the name of your business object; that is, Vbcbo.dll. Then click REFRESH. ClsidView will find any and all instances of that DLL listed in the registry, and allow you to register that DLL as one of the three following options:
NOTE: CLSIDView can only verify ADO and RDS system components through MDAC 2.0. This does not limit its usefulness in managing your RDS server and client components and the registration of your business objects.
REFERENCESThe techniques in this article are demonstrated by the RDS* Series of Samples. They demonstrate the three techniques for returning data in different languages/development environments, but also include a comprehensive business object, as well as a local and remote client for testing and validating that object. The current list of samples available follows: Q183609 FILE: Rdsvb.exe Demonstrates How to Use RDS with Visual BasicThe CLSIDView sample mentioned above may be obtained via the following article in the Microsoft Knowledge Base: Q176562 FILE: Clsidvw.exe OLE/Createable Objects Registry DiagnosticTo see another example of conflict resolution, please see the following article in the Microsoft Knowledge Base: Q177720 FILE: Rdsensub.exe with RDS Conflict Resolution Sample Additional query words:
Keywords : kbDatabase kbRDS150 kbRDS200 kbGrpVBDB kbGrpMDAC kbDSupport kbRDS210SP2 kbMDAC250 |
Last Reviewed: February 2, 2000 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |