3.1.6 - Some field data not saving (was working before)

Classic Servoy
1

Rolled this am’s 3.1.6 release into coding this am and noted this behaviour:

Scenario:

  • Tab (related) Form that is a child to the parent table - rhs of the relation
  • Record add via a simple custom method (controller.newRecord(true))

Previous Behaviour:

  • Worked and tested for adds, edits, deletes

New Behaviour (failure during a Record Add):

  • Persists Servoy columns properly where Servoy is sending default data (e.g. - PrimaryKey or Timestamp from server)
  • Does not persist to the backend db any columns where AutoEnter property is set to None. These columns were working. These columns are not created from the Servoy side - rather, through conventional db model and ddl script generation)
  • These are text columns (no db generated default values, null is ok). Did not test other data types.

Workaround:

  • Added the following lines of code immediately after the controller.NewRecord:

= ‘’ (<-- ie, empty string)

  • If an empty string is sent into the Selected Record buffer instead of a null, all is fine

Postgres 8.2.3-1, Linux RedHat for db host. Win XP SP2 for dev client.

thx, Michael

2

We have a hard time understanding your behaviour change “description”
Some questions:

Previous Behaviour

  1. Which servoy version did you use before 3.1.6?

Does not persist to the back-end db any columns where AutoEnter property is set to None

  1. We have no trouble storing data to columns with “none” as auto enter value in Servoy 3.1.6

  2. Or are you saying that Servoy does not clear columns which do have the “none” auto-enter value in servoy, but have one on db level?

3

Jan,

  1. Was running 3.1.5

  2. Quote: “We have no trouble storing data to columns with “none” as auto enter value in Servoy 3.1.6”. Columns where this is not working for a record add have the following characteristics: (a) Originally created by the backend db (b) are of type Text (c) have no default value set by the db or Servoy (d) do persist/store when an empty string (or any valid string for that matter) is programatically added to the Selected Record buffer immediately after the controller.newRecord(true) function call. The problem occurs only when adding a record and only when a write operation with a null (for a text field) is attempted to the Postgres db.

I also discovered this am that this is intermittent (just what we all love to hear :-)). It seems to be tied into a particular keystroke sequence (ie - when a field is initialized and when it gains focus etc. I will try to find time sometime today to discover the precise (and replicable) sequence of events and advise you. I realize you will need this info on your end. I am using two types of new text fields: one initialized on the backend db and the other via the Servoy data provider column-create function to create a test case. At this point, “sometimes it is working, other times it is not” … so when I have nailed down the exact problem sequence I will respond on this thread.

  1. Quote: “Or are you saying that Servoy does not clear columns which do have the “none” auto-enter value in servoy, but have one on db level?” Sorry - I don’t quite understand your question.

Thanks, Michael

4

Jan,

Here is the event sequence that generates (on this end anyway) a reproducible error (data not posted to the backend db).

The following may be due to incorrect use of the child table controller in (if so, pls advise - I am fairly new to Servoy):

  1. Open Solution and Login
  2. Set of db records selected via conventional Find() and Search() … through code
  3. User selects parent table record
  4. A tab panel containing self-relation Forms (from parent table) and parent-child Forms is visible
  5. User clicks on a Child Table form (in this case, Notes … it is like a CRM application where child table Notes are attached to a parent table - Contacts)
  6. A child record is added. The child record is added from the child form using controller.newRecord(true) … the user clicks on a button to add this record from the child tab/form. I am still learning Servoy so I have not added through the relation or used techniques in the sample CRM (next app!)
  7. I am monitoring the Postgres table via PGAdmin on every keystroke
  8. No db activity yet - the new record is still in the foundset buffer
  9. I type data into one of 3 fields (subject, notes, testnewfield1, testnewfield2)
  10. I tab out of the field I am editing from step 9. No db write yet.
  11. I select another child table record. Db write occurs. Data is properly recorded including seeding foreign and primary keys. Relational tab.
  12. I go back to the child record added in step 6.
  13. I edit a field - one of the fields in step 9 that I had not altered previously in step 9. I mouse click to another field in this same child record.
  14. I move to another parent record via the record selector (Table View in another Form)
  15. I move back to the initial parent record from step 3
  16. I move back to the child record that I had added (step 6) and edited (step 13). My edits from step 13 are still visible.
  17. I issue an F6 to Save Data (Auto Save is on by default in this solution) … I realize that AutoSave is usually doing all of this for me so I conclude from step 11 that a db write should be taking place anyway without the F6 Save.
  18. I move back to any of the parent records.
  19. I exit the solution (step 16 and 17 suggest to the user that the edited data is in the database … me (learning Servoy developer) thinks AutoSave is writing to the db).
  20. I inspect Postgres table - the field edit in step 13 is not written to the database.

Is this behavior correct (ie - I am doing something wrong) or is there a foundset buffer not being written correctly by the event handler? Hopefully, it will be fairly straightforward to generate a test case for the above on your system from an existing application.

My earlier thinking on PG-created columns versus Servoy-created columns may be irrelevant here … I’m not 100% sure. Anyway, the above keystroke and event sequence fails consistently for me.

Thanks, Michael

5

Michael,

We tried these steps and were not able to reproduce the problem.
There is probably a very specific detail that is crucial.

Please create a case in our support system and include

  • a sample solution
  • the table create statements
  • sample data

Rob

6

Rob,

Will do (create a test case). I am tied up today running some year end things for the client and I expect it will take me several hours to create a test environment I can ship you … so I am thinking at least Wed your time before I can get you something.

Over the weekend I was reflecting on our environment a bit more and how I have designed this screen. Here are a few brief thoughts for your reflection while I build out a test case:

  1. The tab panel is comprised of about 10 Forms.
  2. Some of these Forms are classic Parent-Child Forms.
  3. The parent Form that houses the tab panel is “the main parent db table”
  4. This application is, in part, a “data scrub” application. The main parent db table (holding Names, Addresses and Phone #'s - all in one table) will eventually be split into its naturally normalized components like Names, Addresses and Phone #'s). The current record for editing is controlled by the record from this main table. Users select the record from this table’s foundset.
  5. Portions of the main parent db table are “partioned” across several Forms (too many fields for one Form). For example, there is a separate Form for the Addresses. The other 7 or so Forms are the more traditional 1-Many Child Forms and they have a relation set in the tab panel.
  6. The 3 or so Forms that interact with the main parent db table are “Relationless” in nature: I experienced more problems with Foundset synchronizing if these tab-housed Forms were created with a Self-Relation.
  7. I am wondering if there is something fundamental to my approach that is colliding with best practices for your AutoSave or Event Handler approaches: there is quite a bit of “stuff” going on in this tab panel with a blend of conventional relations, relationless and child Forms.

Anyway, I will work ahead on trying to assemble something useful to send you with covering documentation.

Thanks,

Michael

7

Mon pm,

Rob,

Working tonight to build a test case to ship to you. Something changed (in a good direction at some level).

In preparation for building a package to ship you, I took the following steps:

  1. I was running my backend Postgres db with sequences (db managed).

  2. I decided to cutover the Postgres sequences to Servoy managed sequences (in PG I use a BIGINT, not Integer —> values are fairly small at present … well under the limits for integer). So, I removed the defaults for the record add in Postgres and adjusted the data providers accordingly in Servoy … Servoy is now managing the sequence. My thinking was it would be easier for you to recreate the solution test case with Servoy managed sequences.

  3. I went back to get the solution ready for shipment to you. On a last minute hunch, I tried to get the solution to fail using the test sequence in this case.

  4. It ran like a clock! Re-attempted this 3 times … Servoy seems fine at this point (my jury is still out until tested further :-) ).

So, I now have a provisional working solution again (subject to futher testing on this end). I realize this doesn’t deal with the problem described earlier in this thread … simply using a different approach doesn’t mean the problem is really solved.

My two-fold question now is this:

  1. Do you still require a test case via support?

  2. Is there any possibility that something is different in code (in Servoy - at the event handler, Java class, or primary key handlers) between a Servoy managed numeric primary key and that which is managed by a backend db? I would imagine this to be a subtle but important set of events “lining up” where a data buffer/array needed a PK value but didn’t have the PK (or in the right format) when needed for a db-write event.

Let me know what works for you to bring this to a point of mutual satisfaction,

Michael

ps - I am unsure of how to use the Support ticket system … awaiting an email on how to start an incident request.

8

Michael Mooney:
4. It ran like a clock! Re-attempted this 3 times … Servoy seems fine at this point (my jury is still out until tested further :-) ).

That’s great, at least you can continue your project now

Michael Mooney:

  1. Do you still require a test case via support?

  2. Is there any possibility that something is different in code (in Servoy - at the event handler, Java class, or primary key handlers) between a Servoy managed numeric primary key and that which is managed by a backend db? I would imagine this to be a subtle but important set of events “lining up” where a data buffer/array needed a PK value but didn’t have the PK (or in the right format) when needed for a db-write event.

  1. Yes, we would like to get at the bottom of the problem

  2. That should not be related to the problem, the missing db write was an update of an existing record, not creation of a new one.

How to post a case in our support system is listed in the FAQ on this forum: http://forum.servoy.com/viewtopic.php?t=6789

Rob