Hi everyone.

I just recently have delved in the world of linux. (Past installations were passing by). Getting further and further in the world of such a wonderful OS, I am searching for ways to get rid of the proprietary OSes I have installed both at home and at my business.
I was searching for an MS Access alternative.
I found that Kexi has a more clear view of the things that are needed in such an application.
However I find that I have to learn a new scripting language to support the Frontend's requirements. Although Python and Ruby might be excellent tools, I can't find myself enough time to learn new languages.

So I come straight to the point.
In the effort to create an alternative to Access wouldn't it be cool to have support for Gambas (or even another BASIC like language) as a scripting language?

That would have many advantages, such as:
- People coming from the MS world would find a familiar VBA (basic like) scripting language, making it easier to migrate to Kexi and linux in general.
- Further more they would benefit from the Gambas additions like OO programming and other enhancements made in Gambas.
- There would be a more clean way to migrate from a desktop application frontend (in Kexi) to a more sophisticated/complex application in Gambas (such as moving from VBA to VB classic/.net) given the fact that Gambas also supports Kexi's default DB SQLite.
- Maybe the two projects (Kexi, Gambas) could interchange some code (since Gambas uses QT) or even come up with a cooperation plan (given the licensing allows that).
- Even more thing I can't think of now.

Would it be possible to consider this?
(Should I be posting somewhere else)?

Thank you for you time and sorry for the long post.

Dimitrios T Tanis

PS. I've been developing Access based business apps from 2003 and I would be willing to exhaustively test such a given feature, even provide REAL business templates to the community, if such a feature is to be materialized.

Hello Dimitrios,
Thanks for explaining the problem, it is important to be in contact

First, if we ask about vision, the aim of Kexi is to be competitor of MS Access, not a clone. Reasoning for this can be at least based on two assumptions:
1. We have no resources to build a clone.
2. Over time we identified a number of design flaws in MS Access that we wouldn't necessarily duplicate. Please see the note [1] for more info.

Regarding being a clone, there's no point of having 90% of cloned features: old story tells us that you may need the 90% but everyone needs different 90%

Now to the technical part.

Languages: languages are not that different if we stay with imperative, object-oriented scripting. VBA is such, and so are JavaScript and Python and Ruby. While the syntax differs, the semantic is very similar (these are loosely/dynamically typed languages).

There is also no requirement of knowing all the supported languages.

Regarding languages selection, these days I tend to look at JavaScript as preferred language because it's the best known thanks to the Web technologies. Its security (sandbox) is also a value.
For now please note that scripting in Kexi are declared as experimental feature.

Regading Gambas, reusing big projects need devoting real resources from both sides. We reused reports from OpenRPT by (friendly) forking the project, because neither team (Kexi, OpenRPT) felt powerfull enough to support working on a single codebase. Yet, the reuse of Gambas' facilities does not mean automatically we'll be compatible with MS Access VB. We would be just similar in some aspects (langage, object model). And again we and the Gambas developers would need resources for this cooperation.
That said, there's no rule against contributions to a VB support for Kexi if there people wanting to be devoted for this goal. The only requirement is quality of the final solution and not interfering with quality of other parts of Kexi. Kexi is heavily based on plugins, what is technical enabler of such efforts. I am here to help starting if anyone is interested.

The object model. This is the core of my answer. It is very probable that what you invested in is knowledge of the object model of MS Access itself, not the language. See the note [2].

But I have good news for you: Kexi does not try to reinvent too many things there: there are tables/queries/forms/reports (macros planned), record sets, SQL, database operations, etc. So the concepts you know, is something that can help you a lot in transition. Certainly it is hard t odeliver "conversion" tools created for the code, but for data (and maybe queries).

Here I'd like to propose you and anyone to contribute to the further development in the area of importing (or any other), in whatever way you find possible. It can be analysis, advice, use cases; providing sample databases; testing; helping users; participating in costs; and finally -- peacefully evangelization.

The reuse level is also clearly visible at application level itself: if you look at the Table Designer, it resembles the designer of MS Access; (how else would we deliver this functionality?). So we do not seem to suffer from the Not-Invented-Here syndrome, but just use more modern facilities (GUI concepts, networking, languages, XML formats) whenever it makes sense. The facilities that define many aspects of Access come from early 90's.

I hope now you can more clearly see our road to the final scripting feature.

Again, thanks for the topic and feel free to request more information.


Notes:

Note [1]: Some Kexi contributors including me, are ex-hardcore MS Access developers. This type of people know quite a bit bitter misfeatures of Access; let me just mention the plugin system with the "VBA references hell" (see http://allenbrowne.com/ser-38.html).

Note [2]: Object model of MS Access (DAO): http://allenbrowne.com/ser-04.html or DAO: http://msdn.microsoft.com/en-us/library ... 85%29.aspx - defines Objects with Interfaces, Collections, Properties, Methods.

Creating a clone is certainly not the way to go, I second that 100%.
Access has had many bugs dating back to Access 2.0. References hell, autoincrement corruption, tables lockout, weak security, and many many more not expected to be fixed.
Compatibility SHOULDN'T be an issue. Trying to be compatibly would most probably mean trying to be compatible with the bugs also.

I just thought of it as a productivity boost for users coming over from windows.
Allow me to quote what I said over at Gambas forum:

...I think Kexi could reuse Gambas runtime and Gambas IDE itself (which is written in Gambas) providing a "limited" or better "feature oriented" (for database RAD) environment to be used as part of Kexi. This could also provide a future Kexi runtime allowing "applications" writen in Kexi to run without installing the whole Kexi application. Something like Access runtime...

I believe that could create a logical development path, aka users writing "data applications" in Kexi could migrate to Gambas, albeit both being similar yet not clones of Microsoft software (just as a feature). Still it is just an opinion and if that requires a lot of work, I guess I would rather have new features implemented than reimplementing things over with Gambas (Though that "friendly fork" sounded interesting).

Having writen "heavy apps" in Access (over 22000 LOC in my current project) and seeing MS has other plans for Access I would like to move over to Kexi, as it seems to have something to offer. Still it is not possible, but some day I hope I get rid of MS altogether.

To speak the truth I am starting to think about creating an invoicing application in Kexi (ERPs are so much overrated and not needed by more than 30% of businesses using them). However it may just be too soon to start a project like this, since it would require using 110% of Kexi's possibilities.

Anyhow, I would still be glad to offer my help anyway I can. If there is a better place to storm in ideas, let me know.

Thank you for your response.

Creating a clone is certainly not the way to go, I second that 100%.