But with OS you can always figure it out yourself if you try hard enough. Which is impossible in this case because I can’t get to the Servoy Developer Java source code to find out where that little ‘Protect Solution’ bit is coming from so I can either disable it or figure out where it’s getting its password info in the DB.
OK, so in this case it is a bad thing.
On the other hand, isn’t it nice we can lock a solution from our clients?
I know with FileMaker you can buy a password-cracker tool for US$25 which creates a new administrator password of your choice for a protected solution. My question is, is the security in Servoy more robust?
One of my intended projects is a SAAS version of my taxi solution which obviously has no security issues as the user has no access to the code.
However for those clients wishing to purchase my solution to run locally, with Servoy can I be sure that they cannot get into the solution?
The post from the preceding poster seems to imply that this is the case - he obviously has some high level coding skills but still needed to send his solution to Servoy.
Thanks
Steve Taximan
Every product can be cracked. I remember the day that Oracle announced they were unbreakable, the next day over 60 holes were revealed in their security.
Having said that Servoy is much more difficult to crack than many products out there. Until today (knocking on wood) we have had no reports of customers that haid their solution cracked or stolen.
As a sidenote: Historically if your product is so popular that people start cracking it you are making a lot of money!
And: If somebody does actually steal your code this is very easy to prove in court and you can make a lot of money off them!
Dankje wel, Jan.
I doubt that many taxi depot managers would have anything like the skills required to find my (admittedly) simplistic serial number protection system I have built into my existing FileMaker solution.
But it is nice to know that Servoy is on a whole other level up from a $25 password cracker.
I have yet to determine if I will make my entire solution only available as SAAS, or only a simplified version of it, so my concerns might be moot.
Either way, it only reinforces my decision to move to Servoy.
yekinabud:
I did send my DB to Servoy. So I have to sit and twiddle my thumbs while I wait for their reply. I guess that’s what you get for using closed-source development tools.
The problem was caused by a corrupted database, if, as strongly suggested in our documentation (stated as requirement), a transactional database would have been used this would never have happened.
Jan -
You seem to imply that the problem that has cost me 10+ hours of work is a user error. I would like to confirm that is the case so that I can do a better job of avoiding such costly mistakes in the future.
Please point me to the Servoy documentation indicating that a transactional database is ‘required’. I don’t see this under the ‘Supported Databases’ section of the User Guide (or anywhere else).
Also, I believe MySQL tables are specified to support transactions in the CREATE statement with ENGINE=‘InnoDB’. However, when I create a table in Servoy, ENGINE=MyISAM is specified (not transactional).
So how should I have known that A) a transactional database is required, and B) how to specify the creation of the appropriate transactional tables through Servoy Developer?
I can understand that having lost development work is frustrating: been there too. That is exactly why you should always use a transactional database and not use anything else.
That is also why by default Servoy bundles a transactional database and even checks on every repository if transactions are supported: if it isn’t it will even refuse to work. Mysql is a exception to the rule and recently has built a cheat into their driver: even when you run non-transactional it will cheat to the connecting application that you are running transactional and then (like in your case) crash and loose data. Although many people have good experience with mysql in general this is not the first time that data has been lost with mysql in non transactional mode: do not use myisam tables on critical systems and avoid them at all cost!!
I checked our support system and we offered to help you out as well I noticed but you decided not to accept our offer.
I will ask our documentation team to state this more explicitly in all our installation and configuration documentation.
Thanks for your reply, Jan.
I think adding this more clearly in the documentation would help avoid future issues. Thank you.
And thanks for tip on MySQL’s ‘cheat’ behavior - in that case, adding ENGINE=INNODB to the CREATE statements wouldn’t help, since the Servoy app doesn’t know it’s necessary.
I guess all I can do is set the default storage engine to INNODB - but then all of the other applications accessing my DB server will be forced into creating this type of table unless specifically told not to. So I’ll have to see if there are any incompatibilities. I think there is something about InnoDB not supporting text indexes.
As for the offer to help, I was given a cost estimate of 4 hours to ‘unlock’ the solution. I found that estimate to be a bit high, since I’m pretty sure there is a simple method within Servoy Developer somewhere that can be used to solve my problem.
You can run 2 mysql instances, one with and one without transactions. (but not recommended)
Until last week we also where unaware mysql cheated. (after adding the check to the servoy code back in 2001 we must have concluded that making a transaction note in the docs for the repository was not necessary after all)
yekinabud:
As for the offer to help, I was given a cost estimate of 4 hours to ‘unlock’ the solution. I found that estimate to be a bit high, since I’m pretty sure there is a simple method within Servoy Developer somewhere that can be used to solve my problem.
I’m not sure what point you are trying to make here This is not about unlocking your solution but about fixing a corrupt solution (the locking was a side effect of the corruption caused by your mysql without transasctions enabled crashing) to a working one. On what do you base that the estimate is high? We are trying to help, you refuse help and then complain about it, what more can we do?
Jan Blok - I’ve never had the need to run two instances before, but this seems like a good case. I’ll look into it. Thanks.
Jan Aleman - Right - if the estimate was to fix a corrupted DB, then the estimate makes sense - I have no idea how long that could take. But the estimate was to ‘unlock’ the solution, not fix the repository. Isn’t there a method within the Developer code to do this, that you could run in the editor or through a plugin, for example?
I’m not complaining - I’m trying to understand why it is so complicated to set the password if you have access to the source code. If there is no such method, then I’ll have to determine whether paying 4 hours of Servoy consultant time is worth either redoing my work or looking for a crack.
HI,
I know the servoy guys, and if there was a method to unlock your solution, with a simple click they would’nt give an estimate of 4 hours, believe me! They have better things to do!
As Jan said, you were having a corrupted DB, and because of that the solution was locked. So yes, I can believe that in crippled source-code this can be a hell of a job, to restore that.
just my 2 cents…
- Right - if the estimate was to fix a corrupted DB, then the estimate makes sense - I have no idea how long that could take. But the estimate was to ‘unlock’ the solution, not fix the repository. Isn’t there a method within the Developer code to do this, that you could run in the editor or through a plugin, for example?
No, it’s as I mentioned earlier corruption that caused the protection bit to jump in: Servoy checksums solutions to make sure they are sane and protected. I can hardly understand how one can run an non transactional database for serious business software; with a non transactional database it is guaranteed that one day it will crash and destroy your data.