Jump to content
OpenSplice DDS Forum


  • Content Count

  • Joined

  • Last visited

About maurits.dejong

  • Rank
  • Birthday November 25

Profile Information

  • Gender
  • Location
    Hengelo (Ov.), The Netherlands
  1. Hi Roxana, When looking at the provided log-file, I didn't see an apparent error reported by DBMSConnect and all entries logged did end up in the DBMS (and the ones that are missing aren't in the log). The log seems to be truncated though. Was DBMSConnect still running? Perhaps you can provide a simple test-application that reproduces the issue. Furthermore it seems like you have a circular mapping; the table-topic mapping is both written to and read from by DBMSConnect. This normally doesn't yield the expected results. Can you explain what you are trying to do? This is a supported usecase, but requires more configuration. Typically though, communication is one-way. Either in or out for a specific topic. When you are storing strings in the message, using an (unbounded) string instead of a fixed char[] will be more efficient and provide easier access to the string in the DBMS. In the deployment guide the mapping of primitive DDS types to colums in DBMS is explained. With kind regards, Maurits de Jong
  2. Hi Tara, It is not entirely clear to me what exactly you are trying to do. Am I right in that you try to do both DDS -> DBMS and DBMS -> DDS? Can you maybe elaborate a bit on what you are trying to do (or post - a part of - your config-file)? DBMSConnect maps instances in DDS to rows in DBMS and vice versa. If a sample(s) for an instance in DDS is written, the newest sample for that instance will be inserted into to DBMS as a row (or the row will be updated if it already exists). The other way around an insert or update on a row in DBMS will lead to a write of a sample in DDS. A dispose of an instance in DDS will yield a delete of the accompanying row in DBMS and vice versa. Care should however be taken when you try to do a circular mapping (symmetric DDS <-> DBMS mapping). If that is your case, please consult the OpenSplice Deployment Guide chapter 2, which explains a few DBMSConnect deployments. Regards, Maurits
  3. Hi Tara, There is no need to do something special in DDS to get updates on instances stored in DBMS. The logs you are seeing can however be somewhat misleading, which I will explain below. Have you verified that the update actually didn't take place in the DBMS? DBMSConnect makes no assumptions on the existence of a row in the database (there can be more applications working on the table that can delete a previously inserted row). So every sample in DDS will be translated to an insert-or-else-update-like statement in DBMS. If the row was already there, the INSERT will fail. DBMSConnect will then try to do an UPDATE on the same key. If you have logging enabled, this will show as a log containing 'SQLSTATE' and 'native error'. Regards, Maurits
  4. Hi pravin.m.kedar, In DBMS systems the concept of history is not available and since your topic is mapped to a table with the same number of fields, there is no possibility to store the history in the DBMS. An instance in DDS will thus map to a row in the DBMS (if the keys are equal) and the latest sample will be stored in the DBMS. As a workaround, you could create a trigger on the mapped table that inserts the data in another table with a history-column. You can also add a field to your DDS data type that allows you to define the history per instance, and add that column to the key-definition of the DBMS-table. For that to work, you will need to set the option <Mapping ... force_key_equality="false" ... /> in your configuration file for the respective mapping. In both cases, the history-depth will have to be controlled by the DBMS. Regards, Maurits
  • Create New...