Lawful Basis: Contract

There is a lawful basis for personal data processing when the personal data of an individual is required to fulfill a contract obligation or when the individual asks an organization to do something before entering in a contract.
This does not apply when it is reasonably possible to achieve the same goal without processing the personal data.
As always, the action should be documented for justification about the why and how the personal data was gathered and processed.

Contracts

When the personal data processing is required for a contract with an individual, a separate consent is not required.
This is quite simple and straightforward.

When in a special category data is necessary for the contract, then it is also required to identify a separate condition for processing this data.

When the contract is with a child under 18, the organization must consider whether they have the necessary competence to enter into the contract. When in doubt, another lawful basis could be applied, for instance, legitimate interests if it demonstrates that the child’s rights and interests are properly considered and protected.

Rights

When personal data is being processed on the basis of contract, the individual’s right to object and the right not to be subject to a decision based solely on automated processing does not apply. However, the individual has the right to data portability.

Need Help with GDPR?

Get in touch with us if you need help on the subject.

Lawful Basis: Consent

Consent means that individuals are offered real choice and control over their own personal data.
Consent is a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the people data agreement to the processing of the personal data.

Asking for Consent

Consent requires a very clear and specific statement with an explicit opt-in, so pre-checked boxes or other default pre-selected consent methods are illegal.
If the consent includes different purposes or several processing types a separate consent must be asked for each of them.

The statement of why the data is being gathered and what will be done with it must be clearly stated and based on the most appropriate lawful basis for processing.
Therefore, when an individual gives consent, it must be clear for all parts involved what is the consent about.

Public authorities and employers should take extra care to show that consent is freely given, and should avoid over-reliance on consent.

Children merit specific protection with regard to their personal data. Special attention must be give for purposes such as marketing, user profiles and the collection of personal data when using services offered directly to a child.
Ocasional exceptions exist in the context of preventive or counselling services offered directly to a child.
See Article 8 for details.

Auditing Consent

Because consent is auditable, it is necessary to keep records of when, how and what has the individual has given consent to.

Managing Consent

Individuals can manage the consent, including withdraw the consent at any given time.
It should be easy for people to withdraw the consent and that should be stated when asking for consent.

Goal

Genuine consent should put individuals in charge, building customer trust and engagement which will enhance your reputation.

Need Help with GDPR?

Get in touch with us if you need help on the subject.

Interpreting DB2 JDBC error messages

On data migration projects using BD2, sometime there are some awkward DB2/JDBC errors.
It does not matter if it is DB2 on Windows, Unix or iSeries AS/400.

Part of the problem is that the error messages come in localized, on our case in Portuguese, making the debug task a lot harder since it’s almost impossible to find decent help by searching through the error messages. The other part of the problem is that the SQL error codes sometimes are unclear.
Here’s an example of a common problem that we have in data migration projects:

com.ibm.db2.jcc.b.rg: [jcc][t4][102][10040][3.50.152] Non-atomic batch failure. The batch was submitted, but at least one exception occurred
on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements.

com.ibm.db2.jcc.b.pm: Error for batch element #1: The current
transaction was rolled back because of error "-289".. SQLCODE=-1476,
SQLSTATE=40506, DRIVER=3.50.152

com.ibm.db2.jcc.b.SqlException: [jcc][103][10843][3.50.152]
[...] ERRORCODE=-4225, SQLSTATE=null

Following DB2 official documentation:

  • SQLCODE=-1476 means that the current transaction was rolled back because of one of the listed errors, but none of them made much sense since none of the errors identified seem to apply.
  • SQLSTATE=40506 means that the current transaction was rolled back because of an SQL error, which is basically the same as the SQLCODE above.
  • ERRORCODE=-4225 means an error occurred when data was sent to a server or received from a server, which is totally useless.

The real useful information is hidden in the second error message, in the ‘transaction was rolled back because of error “-289”‘ message. The key here is the -289 error.
This error means “Unable to allocate new pages in table space“, and this is the real cause for such a big fuss.

In data migration projects it’s common some of the DB2 table spaces to run out of space. But with such an error message, the error itself is kind of hidden in the middle of the stack trace, all that is shown is a loose error code…
For the sake of the developers productivity, the cause of the error should be highlighted and perfectly visible and understood in order to be quickly identified and fixed.