Reply to topic

Why no Form Wizard? Why Poor Cross-Software Compatibility?

gmcmillan
Registered Member
Posts
1
Karma
0
I'll apologize in advance for the scathing criticism from a non-programmer. I am a small business owner, and it appears that I will have to buy a windows computer and database software for my business due to the failures of kexi and ALL other linux based database software. Here's the story:

I collect data from the public with surveys. This is a core function of my business, in addition to cataloging and analyzing donors and donations. One of the forms I'm trying to create has 87 fields in the table. It is likely that I will create many completely different forms and tables with a similar number of fields over the next few months (if I can manage to create the first one without giving up on open source software). I can make a form that suits my purposes with Libre Office Base's Form Wizard in about ten minutes. To design it from scratch, one text box, check box, label, etc at a time will literally take me days. Unfortunately, Base's output formats will not allow me to export to an mdb format and it is not very sql friendly either. Since all of this data will eventually go on a web page and be used by other organizations on windows systems, this is a critical flaw. I installed Kexi because of its supposed greater compatibility with Access, but I found that this is not really the case. I tried to find another program that would allow me to build databases in sql similarly to the way Base allows me to build and edit forms and tables exclusively in their proprietary and not cross-compatible format, but I could not even find a single linux sql editor that would allow me to edit the database files without being online and connected to the database remotely, which is essential to me, since I often work on the go in areas without wifi.

What is wrong with the linux database programming World today? Are the programmers entirely disconnected from the needs of your customers? I don't think I'm asking too much. I need to be able design tables and complex forms with a wizard like that in base. I need to be able to save these tables AND forms in multiple formats that can be accessed by multiple programs on multiple OS's. I need to be able to design the sql tables and forms for inputting data into them without being required to connect to my own database on my own computer through a network that requires an internet connection. Networking and creating an sql database should not require a small business owner to learn how to program and find hidden mysql sockets and look-up the right port for a specific program, and to put all that info into the proper syntax in a line of sql code. Perhaps most importantly of all though, MY DATA MUST NOT GET LOST DUE TO A GLITCH IN THE SOFTWARE, as has occurred repeatedly in base.

A failure to provide these essential features seems like a failure of the entire linux database programming effort to me. I know you may feel like the hard work you've put into creating this semi-functional program has been a great success, but when I pull out my check-book and pay a thousand dollars to buy a separate windows computer and proprietary database software for this reason alone, I'm going to be thinking of this as a complete failure for you and me both. Why are you wasting everyone's time creating programs that aren't sufficient to accomplish the most essential needs of your end-user? I'm one of millions who will be forced to pay out of pocket for a better solution. This could delay my business dramatically and cost a large amount of money to find a viable database solution, and since we're a non-profit that saves lives in our Community, that means the entire Community is harmed because of this lack of open source solutions. In addition to my problems though, this lack of an open source database that can provide for the needs of small businesses will cause many who could have had a successful business to fail. This is bad for the entire economy. I hope Kexi 3 will be an improvement that makes 2.5 seem like an almost unrecognizable dinosaur, even if it was a first step in the right direction.
User avatar scummos
KDE Developer
Posts
627
Karma
4
OS
Hello,

altough criticism is certainly welcome and frustration about programs not working as one wants them to is understandable, please keep your posts constructive. Sentences like "Why are you wasting your time creating programs that aren't sufficient to accomplish the most essential needs of your end-user?" are bound to annoy developers who spend much of their free time in creating software for you. So, please keep all criticism constructive and focused on the actual topic, as requested by the KDE code of conduct and the forum rules.

I'd also recommend you make a clear list of what crucial features you are missing, since I find those a bit hard to extract from your post.

Complaints about missing support for proprietary file formats in open source software are often better to be directed at the creators of that proprietary format, instead of the people who have to implement it without proper documentation. Wikipedia for example says that mdb does not have a public specification -- thus it will be extremely difficult and frustrating for free software applications to implement import/export for it.

Best regards,
Sven


littauer
Registered Member
Posts
8
Karma
0
I think at a high level gmcmillan has listed his needs. As I interpret it, a forms construction wizard like Access or Base, integration with known-stable FOSS databases and avoidance of proprietary lock-ins.

I sympathize with his frustration and for my usage I share it. I'd far rather be using Kexi or some other FOSS dbgui system but, as he points out, there aren't any.

Database RAD tools right now generate a lot of money for companies that make them and the Kexi project hasn't yet attracted enough programmers so that everything "just works".

His suggestion of specifying use cases that Kexi is ready for is useful as well.

Is there a way we can use his frustration to drive more developers to Kexi? It's plain that the issue is resources, not lack of design talent.

I can't speak for the developers, but if I were one I would find this a useful post
User avatar jstaniek
Moderator
Posts
339
Karma
0
OS
Hi gmcmillan,
Thanks for your post. I'd like to assure we're collecting use cases carefully. Please do not hesitate to continue sharing your thoughts and your cases, this is a great form of supporting the project.

While I am hearing from you for the first time, none of the use cases you mention are truly new for me.

To develop even half of the features you mentioned above is far more expensive than the cost of a new computer with full proprietary stack. Despite that people including me invest not only their free time but also often real money to make project run. Please consider this while encountering pages like http://www.kde.org/community/donations. Just please note this is only indirect donation for advancing Kexi (direct donations are not organized at the moment).

Wizards are so much important that the only more important are core functions like more complete core functions for SQL Queries and Table Designer.

As for forms, they are completely unrelated to SQL tools as we know them. SQL standard does not define forms. I would go through the requests you formed but despite of formal inaccuracies I can read between lines and I understand your needs.

As for the mdb support, there is literally no support for anything but reading table structures and data in Kexi. This is handled using a 3rd-party mdb tools software, impressive achievement of reverse engineering. But mdb tools is not evolving very fast and its quality is not controlled within Kexi. Routines that can write tables and data are neither safe nor reliable (because related knowledge comes from the reverse engineering) so Kexi 'decides' to skip them, what is (we believe) better than putting user's data at risk. Moreover, as you have probably noticed, the format changes since 2007 from .mdb to .accdb still without single sentence on the file format despite numerous complaints and requests sent to the vendor. The other Free software for accessing .mdb that emerged in recent years, probably better than mdb tools is Java-based Jackcess. We have no resources to even try to move to jackcess.

But on a more constructive side, I know how to solve this equation in a reasonable clever and ultimate way but this has to be a funded project of about 2 man-years and probably further maintained. After all, any project that isn't interesting for spare time activities, has to be run using other means. Whether the freedom is worth the cost, depends on the needs, attitude, and finally the pain factor. Many open source projects, Linux kernel, most of the drivers, come from paid developers. The advantage the sponsors get is that they can easier influence what features appear first and when. As littauer has mentioned, I do confirm there's no problem with knowledge.


Best regards, Jarosław Staniek
May I help you? Please include your software version and OS version/name when asking for help.

Kexi - Visual Database Apps Creator, Calligra Suite
Image Image
User avatar jstaniek
Moderator
Posts
339
Karma
0
OS
PS: I'd like add some notes on Cross-Software Compatibility, since it's in the title of this thread. This will show whether the support was or was not very important design decision in Kexi:

- Kexi's aim is to support at least two server backends, MySQL and PostgreSQL (with Oracle as possible third). It also supports dBase and some SyBase/MSSQL Server and not through very limited ODBC interface but via native crafted specifically for each backend. Kexi literally 'deeply knows' specifics of each backend's SQL. It's much more accurate approach than ODBC used in MS Access or JDBC. MS Access natively supports only MS's own MSSQL Server.

- Kexi's support for CSV formats beats many other offerings, including MS Access, especially if you need data type autodetection feature. It ships improvements with every release, for example in 2.6 we're preparing data merging into existing table.

- The format of all Kexi's objects (tables, forms, queries, reports) are specified using XML and thus available for everyone (e.g. LibreOffice Base) to use in importing routines. Kexi Forms' XML is 99% compatible with Qt 3 and 4 .ui format, the word's most successful FOSS UI framework. Kexi Reports format is modeled after elements of OpenDocument Format.
In contrast to that, the format of MS Access is still 100% based on binaries and plagued by memory dump-based security holes (for design documentation of mdb tools explains this). Many former MS Access users (like me) are aware that with MS Access users not only aren't true owners of their designs, but also someone can take ownership of their data far too easily. MS had a chance to escape at least from the secret binary format in 2005 but instead it changed the format from binary to another binary for 2007. That have happened in the same times when MS promoted MSOOXML formats as a big deal (in response to OpenDocument Format's standardization) and harmed reputation of IEC/ISO because of its unprecedented bribery unfair behaviour.

Summing up, we know our current limits but we're hungry to be even more interoperable.


Best regards, Jarosław Staniek
May I help you? Please include your software version and OS version/name when asking for help.

Kexi - Visual Database Apps Creator, Calligra Suite
Image Image

 
Reply to topic

Bookmarks



Who is online

Registered users: ab4bd, Baidu [Spider], BeS, Bing [Bot], Exabot [Bot], GeekQuack, ggael, ghevan, Google [Bot], google01103, igorm, jensreuterberg, kainz.a, maarten, mmistretta, Nuc!eoN, orbmiser, plfiorini, scummos, searchfgold6789, SecretCode, Steve T, TheraHedwig, Uri_Herrera, vblazquez, Yahoo [Bot]