Hi Marcel
No, sorry didn’t explain properly. The whole servoy directory, with its own database folder is always local for developer. I never connect to any other databases from my developer (apart from read only access to a mySQL database which is not part of the problem - for sure (the errors are all in sybase and mysql can’t change the sybase stuff)).
Bevil
I have now been told by my client that this has happened again, this unchangeable number has changed…
Maaaarvellous.
Bevil, you were (in your first post) talking about methods not attached to any event, method etc.
Are they still in place or are they deleted?
the methods are still in place, but the payload is commented out. Those mehods (the ones firing without a trigger) are not corresponding to this error. The untriggered auto methods were looping and deleting a notes file. This error is a unique number changing. The unique number field is not in any method whatsoever…
Is the database attached to any other external application?
Is there an event (or whatever) activated in the database itself?
When there is nothing in Servoy that can trigger this, it is fair to say that it is not a Servoy issue Right?
Hi Marcel
There is a backup event every morning in sybase. It has always been there though and is in most solutions I build…
There is nothing else that touches Sybase…
Any calculation, event or what?
If not I think we are at the end of our rope…
Hi Bevil,
Just a hunch. Is this unique_id anywhere referenced in a calculation ?
Also do you have multiple releases of this solution in the repository ?
TIP: using IT2Be’s Analyzer you might get a better insight in where things are used, even in different releases.
It is referenced in one calculation, but it is a variable, not a product of this calculation.
Yes, there are several releases of the solution…
Neither of these have been a problem before (I got up to 190 releases in this solution before…)
Thunder:
It is referenced in one calculation, but it is a variable, not a product of this calculation.
With Servoy 2.2.x I had an intermitted issue where a calculation ate my BLOB data. This BLOB was only referenced in this calc so I won’t rule out that a calc could be the culprit.
Of course this was a bug and was fixed.
If you are certain this field is only referenced/used on this calculation and nowhere else I then suggest you file a bug report and send your solution to Servoy.
Hope this helps.
Neither of these have been a problem before (I got up to 190 releases in this solution before…)
But you have moved from 2.2 to 3.5 so you had to change things.
Is there not even the slightest chance that you made a mistake somewhere?
Are you referencing the changed column from somewhere?
Hi Bevil,
I don’t use Sybase, but there must be a query log somewhere. Search it to see what you find. If stuff is getting changed, it will be logged.
Also, you can enable the log table functionality in Servoy on the table in question to see if you can catch more clues.
Hi Marcel
I didn’t change things programatically between 2.2 and 3.5. I had a bit of an issue with headers not showing default background colours, so had to change headers to title headers on about 15 forms, but that was pretty much it, there was no programatic change… SHOULD I have changed things (this was my question earlier in this thread - are there deprecated things that might affect methods) What should I have changed??? Besides for this bug, and the fact that the backgrounds on some headers changed, nothing else is affected by the move to 3.5
Christian, thanks for the reply… I have been planning to turn on logging to try to catch this. There is a logfile but I don’t think it is directly readable, it has to be turned on explicitly and then implemented in a form in Servoy. I will try turning on logging…
Thanks
Bevil
Hi Bevil,
I’m a bit surprised you haven’t had to update much code going to 3.5. But I suppose we all write code in different ways. I’m rewriting quite a bit since the introduction of table events in 3.5 allows me to simplify things and get rid of a lots of old code.
Anyway, a few more ideas;
Thanks for all the replies… Gonna try all that later…
In the meantime, if I set an ondatachange on the field, will it fire if the error is not happening with that field being focussed (or for all I know, the form being active)??
I’m guessing it would not, but I’m pulling at straws here…
Hi Bevil,
I don’t believe that onDataChange is going to work for you in this context
This is why Christian suggested the table level events (specifically onRecordUpdate)
Incidentally, one other thought…Have you got any lookups or similar operating which could affect the unique_id column ?
Cheers
Harry
Just a thought…
On a few occasions when I upgraded Servoy it would bring out some programming mistakes I had made that weren’t affecting anything before. Sometimes they weren’t really mistakes but rather I had coded something a little unusual that I shouldn’t of been able to do. Servoys patch would fix them which made a bunch of things go wrong in the upgraded version and I had to go through step by step and fix. In other words, Servoy would look the other way until I upgraded. Sometimes I wouldn’t know about it until later because it wasn’t an error that showed it just changed the function of something.
With such a huge step you may have a few of these in your code.
Steve
Hi Steve
Yeah, Servoy may be complaining about something that I had in my old code. The problem is though, how do I find out what it is??? The problem is extremely rare (happened twice that we know about - with 30 users using the solution every day for several months since the switch)
Harry, I didn’t think that ondatachange would work… Also I have no idea how to do the table level events thing, will have to figure that out… There is NOTHING that could AFFECT the unique_id column. There is one calculation which uses unique_id, but only as one of its variables. Unique_id is not set by anything (until now… I have made a method that will change it manually back when it changes its-self…)
Bevil
I have everything logging so it was just a matter of time to find what changed what. Make sure you have logging turned on. The servoy_log.txt (for errors) and the log_data table (for changes) will expose most everything then your sql program logs the rest.
Hi Bevil,
Another method I have used over time where difficulties persist after normal troubleshooting steps is to first identify areas in code that might be suspect (ie - they can potentially impact the database negatively).
Then, I write what is a effectively a “real-time/production” trace routine as follows:
Write a global function that will receive an array or varchar as an argument and perhaps a few other variables such as calling routine and a brief descriptor.
The sole purpose of this function is to write information passed to it (such as variable states, form/controller state, etc - depends on the function you are doing) and a timestamp, user id. Write to a db table or a network file depending on your preference.
Insert a call to this global procedure at various points in your code identified as potential candidates for a problem area … and write key indicators to this file / db.
The function might also have a dialog that pops up and says “This blah-blah-blah should never happen - please leave your machine exactly as it is and call immediately!” … if this test is applicable to your software.
Has helped me in the past identify some particularly difficult troubleshooting situations as it allows production monitoring to take place beyond what is captured in the db logs or app server layer. Once the suspect condition is isolated, you can then correlate your log data from traditional log sources (db, app layers).
Best as you work this through,
Michael