nSetKeyValue returns 100006 and Triggers VBA Error 438 but sLastErrorMsg is Empty

SOLVED

I'm using the identical code to nSetValue R/W fields that has worked for years, but I am finding that it fails for some tables even though they show a R/W Business Object. I am modifying a non-key field in GL_DetailPosting, but I cannot get past the nSetKeyValue for the first segment of the key (AccountKey). I have verified the key is correct. I get a return code of 100006, an empty sLastErrorMsg value, a VBA Err.Number 438 with the VBA Err.Description "Object doesn't support this property or method". If I ignore the error it re-occurs for each segment of the key and the subsequent nSetKey returns an empty value and also fails with the same VBA Err.Number and Err.Description. If I let it continue and ignore errors the nSetValue returns 0 with a blank sLastErrorMsg and VBA Err.Number 424 with VBA Err.Description "Object Required".

Is there a different method to nSetKey/nSetKeyValue for some tables? How do I know which tables do not allow nSetKey/nSetKeyValue?

  • 0

    What object are you using to modify GL_DetailPosting?

  • 0 in reply to jepritch

    I get the same result with all the ones listed in File Layouts:

    GL_GeneralJournal_upd
    GL_RecurringJournal_upd
    GL_AllocationJournal_upd
    GL_TransactionJournal_upd
    GL_DailyTransaction_upd
  • +1 in reply to connex
    verified answer

    Ah, that explains a few things.  Generally, the _upd objects are not business objects so they do not have the functions like SetKey(), SetKeyValue(), SetValue(), Find(), Write(), etc.  That is why you are receiving strange errors.  Generally, scripting using these objects is minimial.  You can instantiate them and maybe run the associated register and update, but you can't really alter the data in that manner.

    The file layouts list these more for help with UDF data flow.  SetKeyValue(), Find(), GetValue() are functions available for _svc objects and SetKey(), SetValue(), and Write() are functions available for _bus objects.

    Hope that helps

    Elliott

  • 0 in reply to jepritch

    Thanks Elliot. Would you say in general that any table without a _bus object is not editable?

  • +1 in reply to connex
    verified answer

    Yes that would be a great way to put it.  You require a _bus object to add/modify data in a table using scripting.

  • 0 in reply to jepritch

    I suggest then that the "File and Table Listings" not list objects without a "_bus" suffix as "Bus Obj:"

  • +1 in reply to connex
    verified answer

    Thanks .  I think that listing is basically a massaged dump of the dictionary where the list of business objects reside includeing the _upd ones.  These are used as I said earlier for mapping of UDFs, but I'll see what we can do as far as changing that listing.

    Elliott

  • 0 in reply to jepritch

    I suspect that listing is generated from the content in the data dictionary and I don't think it is worth stripping those out with special logic.  As mentioned, I think the surefire way to identify if you can use a specific class to modify records in a given table is to see if the table has a class that ends with _bus. 

    Another approach is to try to create a VI job for the table and if it isn't available then there isn't a _bus class you can use (it seems VI checks the tables custom attributes to locate a class that ends with _bus in addition to checking of the "Exclude From V/I" option is checked). 

    One other approach is to traverse the classes to see if the target class inherits SY_Maint as this is the class that contains the SetValue, SetKeyValue, and SetKey methods.  SY_Service contains the SetKeyValue and Find methods.  SY_Maint inherits SY_Service.