Missing database inserts after update to 2.0.47

If the fields are confirmed to the customers, it means they are in the database. I assume you use #_FIELD{xx} for rsvp mails, and that placeholder gets the info from the db ??
First things first: start by updating to 2.0.48, it fixes other small stuff.
Then, why do you assume the info is not stored in the db?

Hi Franky,

just after my entry I regognized the new version and installed it. But it didn`t fix the issue.

I assume the info is not stored in the db, because I can`t find them in the database by select. If I select by a booking ID I have to recieve seven entries with the field IDs 1,2,6,8,9,10 and 11.

Since the update I revieve only 4 entries for the same statement with different booking IDs: FieldID, 1,2, 6 and 11.

Its curios. I use the #_{FIELD{xx] thats correct. And they are dropdown menues. Worked properbly since this evening. ??

If I look at the bookings from the WP backend, I see also a different choice as it`s mentioned in the email.

Any idea?

Best regards
DieSpeedy

I don’t understand all what you’re saying here.
If it is in the rsvp mail when using #_FIELD{xx}, it is in the DB. How are you doing your select (and also: why would you go directly to the db)? If you’re using a plugin for your DB select: make sure nothing caches!
Also: for dropdowns, check your form field definition, it can have different values for frontend or backend: ‘Field values’ and ‘Field values’ (and also ‘Field tags’ and ‘Admin Field tags’).

Mhm, I try to explain and understand what you are saying. ??

I deleted all cache, just to be sure. And my newest booking has ID 51.
My select statement is as follow:

SELECT booking_id, answer, field_id, answer_id, creation_date
FROM gfktag_eme_answers
WHERE booking_id = ’51’
ORDER BY booking_id
LIMIT 50

And it returns just three rows:
booking_id answer field_id answer_id creation_date
bearbeiten 51 Herr 1 406 2018-09-03 22:05:16
bearbeiten 51 45,- € inkl. Mittagessen 6 407 2018-09-03 22:05:16
bearbeiten 51 Ich habe die Datenschutzerkl?rung zur Kenntnis genommen und stimme zu, dass meine Daten zur Bearbeit… 11 411 2018-09-03 22:05:16

But all other bookings have at least seven rows as results. All fields are mandotory.

What might be intersting, the issue happens just with fields for persons usage. Fields with usage general work properbly.

Could it be that there is a a commit missing? So the email will be generated, but after that the answers not commited?

Does those information help to understand the problem?

Best regards
DieSpeedy

I am using adminer for SQL and went to the database due the csv-export issue which apperead again. ??

Regarding the field definitons I`m fully lost. I just definied a field name, field typ, usage of field (for persons) and the values.

The values are: WS1.1 Bedürfnisse kl?ren: Das innere Team||WS1.2 Denkst Du noch oder fühlst Du schon?||WS1.3 Das geh?rt sich so! – GFK mit Kindern

It worked properbly before with this settings, that`s why I am really confused.

Now that is interesting: “the issue happens just with fields for persons usage”
That’s something I can test! Let me get back to you.

Edit: I just thought of it: fields with purpose “people field” are NOT stored with the booking, but with the person. The reason is that they are “personal”, so the info is related to the person too. The idea behind this is that you can ask for all kinds of personal info while people are registering, and the info will be stored with the person.
Of course, when doing a booking report, the personal fields are not reported (since not related to the booking, but to the person that made the booking).
So: check the person and you’ll find that info. If you don’t like that, don’t make it a “people field”, but generic.
It is also marked when creating the formfield: “If you select ‘People field’ and use this field in a RSVP or membership form, the info will be stored to the person, so you can ask for extra personal info when someone signs up. When editing the person, those fields will then be visible.”

• This reply was modified 6 years, 6 months ago by Franky.
• This reply was modified 6 years, 6 months ago by Franky.

Hui… okay, I really don`t understand what changed, because it worked with this configuration since June and the results in the DB have all been stored in the eme_answers for the booking_id.

But now I changed it to a general usage field and the next test booking was fine. I`m irritiated, but released.

I will observe this the following days, but hope this will however be the fix. ??

Thank you very, very much!!!

It is in the changelog:

= 2.0.42 (2018/08/21) =
* Formfields of type ‘people’ are now stored per person, so you can ask for extra personal info during rsvp or membership signup

Using a “people field” in a rsvp form would’ve been useless (but it worked as any other field before). The “People field” was always special, as indicated when creating a formfield, and since last week I started using it for what it was meant to be in a rsvp form too ??

?? Great, that makes it clear! Thank you for clarifying. Now I am totally realeased and learned to read the changelog more carefully. ??

Thank you!!!