So, in this case, every request for the next part of the iterator will resend the, , and elements.
Remember, every subsequent request request using this iterator must use the same search criteria and that search criteria must be sent with every request. You'll then check the iteratorRemainingCount attribute and, if it's greater than 0, send your next request using the iteratorID attribute. Notice that QuickBooks has sent us back an iteratorID=”…” attribute and an iteratorRemainingCount=”…” attribute, indicating the ID used to identify the iterator, and the number of items left in the iterator. QuickBooks will send you back a response containing the first five (5) customers that looks like below.
Notice that we declare the iterator=“Start” attribute to start our iterator: OwnerID is 0 (this just makes sure we get back DataExt values (custom fields) defined in the GUI) This query fetches customers with the following criteria: Iterators are documented here, and further documented on page 115 of the QBSDK_ProGuide.pdf in the SDK documentation.īelow is an example of using iterators to query for a customers, fetching five (5) customers at a time. Iterators ask for a query to be split into multiple result sets, and you then retrieve each part of the entire result set individually, so the data transfer for each part is much smaller and faster. You can solve this problem using iterators. This is because the resulting XML from some queries can get so large (imagine sending 15,000 customer XML records over the network, it's usually a several megabyte XML document) that the SOAP server/web server/Web Connector rejects the response or refuses to wait for that much data to transfer. You might find that when querying for large result sets, you get HTTP time-out errors, Web Connector time-out errors, web server time-out errors, or web server data-overflow errors.
0 kommentar(er)
