Servoy 3.5.5, very occasional data loss?

Hi all,

trying to work out whether I’m dealing with user error, programmer stupidity or a Servoy bug.

About twice a week some user will complain that some text they have entered has disappeared. Typically, the text has just been input into a TEXTAREA on a related tab panel. Some times, the just beginning of the text is saved. It is as if Servoy thinks the text is shorter than it really is.

The field is a variable length ‘text’ field. No action connected to the TEXTAREA. The database is PostgreSQL.

We had a similar, much more frequent problem in version 3.1.x, which disappeared when we upgraded to 3.5.x.

Have anybody else seen this problem?

Server and clients on Mac OS X 10.4.x.

Servoy version 3.5.5-build 518, repository version 31
java.vm.version=1.5.0_06-68
os.name=Mac OS X
os.version=10.4.7
os.arch=i386

Hi Christian

Are the Users on a good connection? We had a similar problem with a client roving the USA and connecting through a mobile EVDO data link with variable (usually slow) speeds and high latency. The problem seemed to be that they would lose the connection - without realising it - continue typing in TextArea’s then could not save the latest data.

Seemed to be resolved by creating a WebClient version with specific save button - although latest versions of Servoy seem to be more tolerant of dropped connections.

HTH

so something is changed?

They typed in at once a full sentence (and there was nothing) and then half the sentence is saved?

It looks to me that that only can happen if the database column can only hold that much chars…

I’ve battled with this problem in a large solution for a while now.

In my case, I’ve gotten it pinned down to some instances where the user will be in the field and able to type, but Servoy is not in “edit” mode (ie, no little ‘e’ in the status bar).

It’s always in a related tab, usually in TEXT_AREA’s, but also in TEXT_FIELD’s. It seems to occur when the user is in the field editing, clicks somewhere else, then back, and the cursor is still in the field allowing them to edit, but when they are done the data is not saved.

I’ve been able to pretty successfully workaround the problem in this solution with a temporary hack that sets focus to a field in the navigation sidebar in the onShow method of the tabs – but I’ve never been able to put together a solid test solution that reproducible to put in the support system.

I’d be interested if you’re seeing the same problem as I am.

greg.

I’ve battled with this problem in a large solution for a while now.

In my case, I’ve gotten it pinned down to some instances where the user will be in the field and able to type, but Servoy is not in “edit” mode (ie, no little ‘e’ in the status bar).

It’s always in a related tab, usually in TEXT_AREA’s, but also in TEXT_FIELD’s. It seems to occur when the user is in the field editing, clicks somewhere else, then back, and the cursor is still in the field allowing them to edit, but when they are done the data is not saved.

I’ve been able to pretty successfully workaround the problem in this solution with a temporary hack that sets focus to a field in the navigation sidebar in the onShow method of the tabs – but I’ve never been able to put together a solid test solution that reproducible to put in the support system.

I’d be interested if you’re seeing the same problem as I am.

greg.

would be good to have a reproducible case for this.

Hi all,

the users are on a LAN, so the connection is good.

In the backend database the field type is ‘text’, i.e. the field should store whatever length you give it.

We don’t use Find mode at all in Servoy, on_find_command is redirected to special search fields which work in data entry mode.

It seems the text gets cut at some point in the middle when saving. As it is not happening that often, I can’t give you any more info.

Greg, are you on Mac OS?

I am, but the solution is deployed on Windows, Java 6 with all Windows clients.

g.

Greg, what database are you using?
And what type of primary keys?

Looks, like this is not OS specific.
And maybe not database specific either…

MySQL, Servoy sequences. But I don’t think that has anything to do with my problem.

Servoy is just not thinking that it’s in edit mode, and never fires an update to the db.

greg.

Thanks for the info Greg, let me sum up:

This issue is

  • not OS specific (both Mac OS, Windows)
  • not Java-version specific (both Java 6 and 1.5)
  • not database specific (both PostgreSQL, mySQL)
  • not key-generation specific (both Servoy sequences, DB identities)

Sounds like some bug in Servoy itself.

Is Autosave on ? or are you using your “own” Save

Others things to consider:

  • transactions
  • record locking
  • network/router issues

I had been avoiding this problem, but just spent some time on it and opened a case (136387) with a reproducible bug.

My case may be different than Christian’s, however. Don’t know. It appears that in my solution the problem is actually tied to having an “onShow” event in the form showing in the tab.

greg.

Hans Nieuwenhuis:
Is Autosave on ?

Yes.

grahamg:

  • transactions
  • record locking
  • network/router issues

I’m not using any transactions, or locking any records manually.

agiletortoise:
I had been avoiding this problem, but just spent some time on it and opened a case (136387) with a reproducible bug.

Great.