On 25 August 2010 10:45, AC. <achuan...@gmail.com> wrote: > The cause I change the question suddenly is > 1. My tables are big sometimes. > 2. When the table B was the big one and I wanna get table A, > it wastes time and resource to get a *BIG* table B that I don't neet it.
If your tables are big, then I *strongly* suggest you use a more efficient approach than the iterate helper. Personally, I tend to go for the table_data helper, together with a local cache. Robert would probably advise you to use the MfD framework. (And although I don't like it myself, this should also work more sensibly in this situation). But bear in mind that although a walk of table A will trigger a query for the next OID supported by the agent, this won't involve walking the *whole* of table B. There should only ever be one value returned from table B (being the value immediately following the last entry of the last column of table A). So it should be a one-time overhead of loading the data, plus a single pass through the get_first/next hooks, and one invocation of the table B handler (for one column value). If this continues to be an issue, you could always tweak the MIB to define a scalar object lying in between the two tables. So walking off the end of table A would retrieve this buffering scalar value, rather than loading table B. Dave ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
