TBH most of those numbers from outside reviews are AT BEST wild assed guesses
Since Xojo is 100% privately held they dont report an publicly accessible revenues salaries etc
From experience I can say when I worked there the #’s reported by such sites were not in line with what we were told internally
Overall activity is way way way down over the last several years
That seemed to started somewhere after my departure and has seemed to accelerate since Web 2 and Api 2
Looking on java forums I can’t see that xojo forum is more active. Definitely not at all. Looking on stackoverflow I can see more activity than in the Xojo forum. But hey, XoJo has millions o users 
Geoff doesn’t even login any more… Last time Geoff did’t login for a long while someone said he disconnects on vacation. Sure seems like a lot of multiple week vacations…
forgive me but what isn’t true at all. Even the B4x forum has more activity. And the Java plugin world has more uses than xoJo ever had users every day. So I am sorry but the “business” of XoJo is anyhow a minimum business. Will you really tell anybody that XoJo is in the same state like Go, Java, C#, C++, Python and others? I doubt that. Okay, no. I know definitely that Xojo has a few users while Java, C# and C++ having many. There is one big difference: Xojo is a niche player. This niche isn’t a real one while you can program for all platforms with QT, with Kotlin, with Java, with C#. There is no: only Xojo can do that. Far away from that. And there is no: only Xojo has the right tools. Also far, far away from that. In fact: Xojo is a minimal player and it’s niche is decreasing more and more. Their structures are too small and they have nearly no development power. Vendors like Azul having hundrets of developers. Not 5. C# is developed and maintained by hundreds of developers, golang also. And Python…let’s not speak about. Languages used by multi million people are not in the same situation. They dan develop and they do it. They build up technology. Xojo is not rally building up technology. Xojo Android is the best example: based on Kotlin by Jetbrains. And the API: around 10% of the API. Not even a table view with multiple columns. That is the reality behind Xojo. And this you’ll find also for iOS, macOS, Windows and Linux. Beside the poor performance of Xojo apps compared with Java, C++ or Golang. Wow. That’s really poor.
So how can anybody believe that this is a secure platform to rely new projects on for the next ten years? Spending two years development in a project and then what? End of story while it is dead? There is no reason any more to do that. And no need.
he may be busy working on the next version of super-duper DBKit beta 
wake me up if DB-kir reaches the functionality of DataGrip from Jetbrains
wake me up if DbKit has ANY functionality worth talking about
okay you made my day and you’re topping me definitely
Enjoy your VERY long sleep Rip Van Winkel 
To be fair, it could be useful for beginners and it tries to make it easy to use DB’s with Xojo UI. I have watched a demo and looked at code (been a while on the code since I don’t care all that much). He’s aiming for something like FileMaker or 4D type of easy UI/DB coding. But rather than scanning the db/table and presenting a popup menu you have to type tables and column names in.
It does the easy stuff fairly well. However, it lacks basic record-locking capabilities and when I brought this up to Geoff he, at first, said that was handled by the db plugins (they don’t) and when I pushed farther he said that’s an ‘advanced topic’ and beyond what DBKit is supposed to be doing. So essentially if anyone using it is in a multi-user environment ‘last to save wins’ since there’s no locking/checking/warning messages. It’s simply irresponsible.
Most of the Xojo projects I did as a consultant were db driven. You can do simple record locking (i.e. read and compare the last modified timestamp of the record) or do some pretty crazy, nasty-assed shit with tables that track what records are currently open and locking users out from being able to edit/update but then you have to have all sorts of mechanisms in place to ‘override’ or take the lock away from someone. Regardless, DBKit doesn’t even attempt to protect a user from themselves. Doing a simple version would not be hard but that would require that Geoff understand the need and then figure out how to do it.
I don’t remember if it worked with views or not. I’d guess not. I seriously doubt it handles complex relationships very well either. If it’s simple you’re fine (well, except the record locking). I’m sure if I spent any time looking at it I could come up with a dozen things that make it not suitable for any real work.
But then again, why would I trust Xojo to do real work any more? I’m not their target audience and neither are hobbyists, apparently. 
no locking? I dare to ask: What’s with Transactions?
ah I forgot… this is super-duper-special-ahaed-advanced
Its increasingly hard to figure out who IS their target
Pro’s arent - the things they report bugs about and ask for arent getting done with any expediency
Hobbyists arent - this thread & the price increases getting rid of affordable options for hobbyists show that
And citizen devs face those same price increases and dont seem to be too happy about them either
so who IS ?
Fanboys who pay each year just to support them, devs who dont like curly braces or creating GUI programatically and the poor souls traped with big proyects to maintain 
Transactions dont assure that two users do not overwrite each others changes though
Depending on how the app is architected it could be
user A “opens” a record to edit it - but this doesnt lock the record
user B “opens” a record to edit it - but this doesnt lock the record
Now if user B saves then user A saves users A’s changes may overwrite user B’s (or vice versa)
Holding a record locked while a user edits it can lead to db lock up if User A goes away for a long time and doesnt save
One responsible way to do this is for both to be able to open the record and the second to save gets rejected because it checks the timestamp it has for the record to make sure it has not changed before their data is saved
Another, as Bob noted, is to track what records are open and disallow the same record being opened as editable
DBKit does neither
yes, at least transactions can be rolled back in case of any conflict… esp… when updating across multiple tables…
you forgot the addon-devs, who try to offer you their addons…
Yes transactions can be rolled back
But if the update is just “update where record is = X” then it wont help
Detecting the conflict is the issue
If user A commits using a transaction and user B commits using a transaction then you still have “last edit wins”
And you dont want to use transactions as an edit control mechanism (ie do not use select for update) as that can result in DB deadlocks
Been there seen that happen
So you need a policy like “we dont permit multiple people to have the same record open to edit at the same time) and a mechanism in the DB to support it
Or some other policy with a supporting mechanism
The DB can only do so much to help here
so true!
