| View previous topic :: View next topic |
| Author |
Message |
liherb
General User
Joined: 19 Aug 2011
Posts: 38
|
 Posted: Tue Oct 25, 2011 10:18 am Post subject: [solved] Can I export queries? |
 |
|
I know that you can export tables, but queries seem to be locked in one particular database management system. If I developed a lot of queries with BASE, and then I wanted to develop my own front-end client using Python, how can I port all those queries to the new client? Do I have to rewrite everything?
By the way, is there a way to port inter-cell relationships in Calc to Base? When I tried to copy and paste a spreadsheet from Calc to a Base table, all the references seem broken.
Last edited by liherb on Sun Jan 01, 2012 2:53 pm; edited 1 time in total |
|
| Back to top |
|
 |
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Tue Oct 25, 2011 11:37 am Post subject: Re: Can I export queries? |
|
|
| liherb wrote: | | I know that you can export tables, but queries seem to be locked in one particular database management system. |
The Base front-end stores the Query definitions. Those Queries can be converted to Views for storage in the back-end RDBMS. That may suffice in your case since you're looking at a front-end replacement. If your front-end replacement project will include replacement of the back-end RDBMS, then you've got some other considerations. First, you can stick with the built-in HSQL RDBMS for seamless migration of all back-end components (Tables, Data, Views, etc.). Or upgrade to HSQLDB 2.x for virtually [typically] seamless migration. Or if you choose another back-end, understand that View definitions are read-only. But as Views the definitions can be exported using the SQL SCRIPT command for syntax adjustment and INSERT back into another back-end RDBMS. So the particular SQL syntax may be locked into a particular (back-end) RDBMS choice, but only because SQL standards evolve over time and few RDBMS's implement the standards precisely or fully in the first place. But third party tools are widely available for back-end migration, perhaps with varying degrees of success.
See also: http://www.oooforum.org/forum/viewtopic.phtml?t=32333
| liherb wrote: | | By the way, is there a way to port inter-cell relationships in Calc to Base? When I tried to copy and paste a spreadsheet from Calc to a Base table, all the references seem broken. |
A spreadsheet can be a flat-file database table, but can only be exported in it's static form (final values). A database does offer aliases and/or computed columns while a spreadsheet uses cell references with functions, but there's no seamless port that I'm aware of.
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases' |
|
| Back to top |
|
|
liherb
General User
Joined: 19 Aug 2011
Posts: 38
|
| Posted: Tue Oct 25, 2011 5:17 pm Post subject: Re: Can I export queries? |
|
|
| dacm wrote: |
| liherb wrote: | | By the way, is there a way to port inter-cell relationships in Calc to Base? When I tried to copy and paste a spreadsheet from Calc to a Base table, all the references seem broken. |
A spreadsheet can be a flat-file database table, but can only be exported in it's static form (final values). A database does offer aliases and/or computed columns while a spreadsheet uses cell references with functions, but there's no seamless port that I'm aware of. |
Last edited by liherb on Tue Jan 03, 2012 5:21 pm; edited 1 time in total |
|
| Back to top |
|
|
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Tue Oct 25, 2011 11:47 pm Post subject: Re: Can I export queries? |
|
|
| liherb wrote: | | ...if I want my data highly portable across different platform and database client applications, Base is a better choice than Spreadsheets. Can I safely conclude this? |
Not exactly, because a Base .odb file is proprietary and exclusive to OOo/LibO.
In a portable, cross-platform context, the progression is probably:
(1) spreadsheets/CSV,
(2) then dBase table-files/folder,
(3) then native RDBMS files/folder
You see...
Option 1: Base can create an all-in-one database file (.odb) where all database components are stored within a single zip-archive file. This includes Forms, Queries, Reports, Macros and database files (schema and data). However, this portable file is accessible exclusively with OOo/LibO; there's no external drivers available to access the database components using other clients. And this is not a reliable configuration so it should never be used for production data.
Option 2: Base can also be configured to connect to stand-alone data while storing only the connection information plus any Forms, Queries, Reports and Macros in the .odb file. This is the more flexible configuration because you can connect to various data-sources such as a spreadsheet/CSV/address-source (all read-only), a folder full of dBase table-files, or a full-blown RDBMS. And if Base can connect to it, you can be sure that other front-ends (database clients) can do the same.
So in your case, you want a portable, cross-platform database for use with Base and other front-end options. No problem, just use Option 2 above. I'll presume by "portable" you mean the database files. And I'll presume you would prefer a "cross-platform" RDBMS solution. AFAIK, all cross-platform RDBMS's generate portable database files. So simply choose a compatible, cross-platform, back-end RDBMS.
But if by "portable" you mean the RDBMS app as well (not just cross-platform but no installation required and written to a ubiquitous framework like Java), then you're narrowing the choices to something like HSQLDB or H2 rather quickly. An older version of HSQLDB is built-into OOo/LibO, so it's readily available for external connection either with Base or otherwise. See my signature links for more information below.
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases' |
|
| Back to top |
|
|
liherb
General User
Joined: 19 Aug 2011
Posts: 38
|
| Posted: Wed Oct 26, 2011 6:24 pm Post subject: |
|
|
For my case, multiple-user is not an issue at all. My situation is, I want to start with a database application dealing with personal medicine tracking in a general purpose platform (e.g. Base or Calc), and then eventually progress to Python programming to build my own dedicated application on top of the accumulated database.
In this process, I will inevitably produce a lot of queries (or formulas, in case of using Calc) on top of my data. Actually it is those queries not the data itself that takes most of my time. If those queries and formulas cannot be ported seamlessly then it means I will have to spend a lot of time rewriting all the queries and formulas when I do the progression to Python GUI. Now after reading this thread, I've learned that the possibility of porting queries among different applications is YES to databases and NO to spreadsheet. That really helps my decision. Thanks.
Do you think HSQLDB works well with Python? I see a lot of Python GUI builder does not support HSQLDB back-end yet (e.g. Dabo). How about SQLITE? Can I convert Base queries into Views then port them to my own Python application SQLITE database? |
|
| Back to top |
|
|
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Thu Oct 27, 2011 12:03 pm Post subject: |
|
|
| liherb wrote: | | Now after reading this thread, I've learned that the possibility of porting queries among different applications is YES to databases and NO to spreadsheet. |
Well...lets be clear. A spreadsheet can serve both front-end and back-end functions.
A Calc spreadsheet (and therefore an Excel spreadsheet after import into OOo/LibO) can serve as a portable, cross-platform, front-end to a database. If the data is stored in a flat-file database -- whether in a separate spreadsheet-tab or in a standalone CSV file -- then front-end function is limited to available spreadsheet formulas or pivot-tables (and perhaps macros) for data manipulation and analysis. Queries simply aren't part of the equation in this case because there's no SQL engine involved. And keep in mind that spreadsheet formulas don't port well to any other front-end solution.
But, a Calc spreadsheet can be connected to an SQL database engine -- through a Base file (.odb) which can include stored Queries, Forms, Reports, and Macros. So that's a spreadsheet (front-end), connected through a Base .odb file (front-end), to an RDBMS (back-end SQL engine and associated database). And it can all be completely seamless with an "in-process" database engine like HSQLDB, H2, Derby or SQLite. You'll simply click on the spreadsheet file to open it in Calc, and the "data source" is available automatically without managing a database server app. So that approach, in effect, adds Queries to a spreadsheet front-end solution, by using Base sandwiched in-between serving as the connection to the data source and as a storage container for the front-end components: Queries, Forms, etc. The Query definitions can be ported directly to any other front-end using the same back-end database and engine. Export of those Query-definitions can be done individually with copy-&-paste, or exported to a text file using a [available] Macro.
| liherb wrote: | | Do you think HSQLDB works well with Python? I see a lot of Python GUI builder does not support HSQLDB back-end yet (e.g. Dabo). How about SQLITE? Can I convert Base queries into Views then port them to my own Python application SQLITE database? |
More on this later...I've got to run an errand...
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases'
Last edited by dacm on Sun Apr 01, 2012 8:55 am; edited 3 times in total |
|
| Back to top |
|
|
liherb
General User
Joined: 19 Aug 2011
Posts: 38
|
| Posted: Thu Oct 27, 2011 6:22 pm Post subject: |
|
|
Hi dacm, it's so sweet of you! and very helpful! 
Looking forward to your comment on HSQLDB and python....
And of course, many thanks. |
|
| Back to top |
|
|
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Fri Oct 28, 2011 2:20 pm Post subject: |
|
|
| liherb wrote: | | Do you think HSQLDB works well with Python? I see a lot of Python GUI builder does not support HSQLDB back-end yet (e.g. Dabo). |
According to my quick research, HSQLDB should work well with Python and related frameworks like Dabo. HSQLDB runs in the standard JRE and uses a standard Java Database Connection (JDBC). There's no native support for JDBC in Python's DB-API, but several Python-Java bridges will add the necessary support.
Some Python JDBC options include:
1. JayDeBeApi 0.1.3 (a direct bridge from JDBC to Python's DB-API)
2. PyJdbc (similar to JayDeBeApi but CPython exclusive)
3. Jython's database connectivity options (native JDBC support in Python)
The third option above is noteworthy because Jython is Python written in Java (just as CPython is written in C). Jython takes the cross-platform model to unprecedented levels while opening up the possibility of using any Java class to include GUI's with Swing, SWT or the built-in AWT. Plus, Jython offers thread-safe concurrency for processes with multiple threads due to the Java roots, whereas CPython has concurrency issues. Of course, you don't need to know anything about Java to use Jython with HSQLDB (anymore than using CPython with SQLite involves learning C). Java is a framework layer, but all cross-platform frameworks for Python involve multiple layers. For instance, Dabo is written in Python atop the wxPython GUI toolkit, which is written in Python atop the wxWidgets C++ library, which utilizes the platform's native API. Modern computers yawn at layered frameworks for 2D applications like database front-ends which don't involve intensive 3D graphics. In database applications, performance bottlenecks center around the RDBMS engine -- so I agree with Steve Menard's response found here. But I do understand that programmers love diversity, and a Java-free approach to cross-platform is the challenge of our day -- albeit heading away from API-based frameworks like Python towards web-frameworks like HTML5.
| liherb wrote: | | How about SQLITE? |
Good question. SQLite could be adequate and it's included with Python, and supported natively in Dabo. So that might ease setup down-the-road for CPython+Dabo+SQLite; whereas it might complicate setup with Jython+Dabo+SQLite. But you'll want a compatible database manager to build the database with SQLite. Once you've got the database structure, connect Base through ODBC, where you can build your Queries/Views. If they're saved as Views, there's no need to export them when moving the front-end to Python/Jython.
| liherb wrote: | | Can I convert Base queries into Views then port them to my own Python application SQLITE database? |
That's not as easy or seamless as you might think. Once again, if you save your Base Queries as Views, there's no need to export them...as long as you're using the same back-end RDBMS. Otherwise, the legacy HSQLDB 1.8 version included with Base is almost as crippled as SQLite in terms of modern SQL support, but SQLite really departs from the standards for data-types and built-in functions so you would be forced to do some major re-work. And if you start with something like HSQLDB 2.x, H2, PostgreSQL, MySQL, or Firebird with Base, you'll find the move backwards to SQLite more trouble than it's worth.
I would just pick an RDBMS and stick with it:
Base+SQLite^ >> Dabo+Python+SQLite^
Base+JDBC^* >> Dabo+Jython+JDBC^* or Dabo+Python+PyJdbc+JDBC^*
Base+Firebird >> Dabo+Python+Firebird
Base+MySQL >> Dabo+Python+MySQL
Base+PostgreSQL >> Dabo+Python+PostgreSQL
^ indicates in-process (embedded) mode available for seamless, single-user access.
* JDBC = HSQLDB 1.8, HSQLDB 2.x, H2 or Apache Derby.
Bottom line: (choosing a single RDBMS for use with Base and Dabo)
1. If you think SQLite will suffice, then go with it.
2. If you need better standardization and feature-depth for your Queries, then consider HSQLDB 2.x or H2 (or Apache Derby if the speed is deemed sufficient)
3. If you want to get into writing your own SQL stored procedures, then choose HSQLDB 2.x (over H2 or Derby)
4. If you don't mind starting and managing the database server separately choose between MySQL/MariaDB, Firebird or PostgreSQL.
BTW, OOo/LibO offers to install Python 2.6.1 during installation for use as a Macro language in OOo/LibO.
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases' |
|
| Back to top |
|
|
liherb
General User
Joined: 19 Aug 2011
Posts: 38
|
| Posted: Wed Nov 02, 2011 8:21 pm Post subject: |
|
|
| dacm wrote: |
I would just pick an RDBMS and stick with it:
Base+SQLite^ >> Dabo+Python+SQLite^
Base+JDBC^* >> Dabo+Jython+JDBC^* or Dabo+Python+PyJdbc+JDBC^*
Base+Firebird >> Dabo+Python+Firebird
Base+MySQL >> Dabo+Python+MySQL
Base+PostgreSQL >> Dabo+Python+PostgreSQL
^ indicates in-process (embedded) mode available for seamless, single-user access.
* JDBC = HSQLDB 1.8, HSQLDB 2.x, H2 or Apache Derby.
Bottom line: (choosing a single RDBMS for use with Base and Dabo)
1. If you think SQLite will suffice, then go with it.
2. If you need better standardization and feature-depth for your Queries, then consider HSQLDB 2.x or H2 (or Apache Derby if the speed is deemed sufficient)
3. If you want to get into writing your own SQL stored procedures, then choose HSQLDB 2.x (over H2 or Derby)
4. If you don't mind starting and managing the database server separately choose between MySQL/MariaDB, Firebird or PostgreSQL.
BTW, OOo/LibO offers to install Python 2.6.1 during installation for use as a Macro language in OOo/LibO. |
After considering all the factors, I think I will go for the "Dabo+Python+PyJdbc+JDBC" option. One more question, does this option fit with RDF/XML database? I plan to include a lot of stored webpages and want to integrate my database, my Python application and my stored webpages in an organic ways. could you comment a general idea about this? Thanks. |
|
| Back to top |
|
|
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Thu Nov 03, 2011 7:05 am Post subject: |
|
|
| liherb wrote: | | does this option fit with RDF/XML database? |
Is that a common role for a relational database? I would think that meta-data would be a logical fit for a relational database, but it may be better suited for an object-oriented (distributed) database system. I don't have any experience with object-oriented databases, unless distributed Javascript libraries/objects as they exist across the web qualifies. You could certainly store the URI's as text strings (VARCHAR), or the RDF/XML as multi-line text (VARCHAR). Storing complete web pages/sites including media would probably require BLOB/CLOB support. BLOB/CLOB data is well supported as you upgrade from the built-in version of HSQLDB (1.8.0), but actually storing/retrieving the LOB data is another matter. For instance, Base Forms only support images (JPEG, etc.), so other LOB data would require other means to load and retrieve.
I'll leave this question open to others with more experience in these areas...
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases' |
|
| Back to top |
|
|
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Thu Dec 29, 2011 9:30 am Post subject: |
|
|
| liherb wrote: | Hi dacm,
Thank you so much for all your replies to my posts, which are very informative. I still have one issue that is not settled and really like to seek some of your advice.
In those posts we came to the conclusion that OOo Base does not perfectly support non-embedded JDBC up to the latest version. We've also discuss about the "Dabo+Python+PyJdbc+JDBC" solution. So my question is, given Base's current shaky support for non-embedded HSQLDB, is it a good idea not using Base as GUI front-end at all if one really wants to use the full potential of HSQLDB? How much steeper is the learning curve for a beginner to start out directly with "Dabo+Python+PyJdbc+JDBC" solution rather than the Base solution?(I know this is likely to be a subjective question, I only wanted to know how much more efforts I need to be prepared for the Dabo solution and I would particularly appreciate your opinion rather than my own subjective assumptions! )
I really want maximum flexibility with my data design in my own project and make use of the full potential of modern database management system, that's why I'm not satisfied with any Spreadsheet-like programs and ambitiously starting to build my own database application in the first place. However, I'm really novice to both HSQLDB and Python programming. I have plenty of time and this is my only hobby though. Do you think grasping HSQLDB by "Dabo+Python+PyJdbc+JDBC" route for a newbie is attainable? Thank you very much! |
Forgive me, but the answer to your question could benefit the greater Base community in general...
If I understand your project correctly, you're seeking to build a seamless, database-driven, desktop application for the storage and analysis of personal medical data. Stored web links (URL's) and perhaps files (images or PDF's) are also involved.
And now you're asking if it would be easier to learn Python+Dabo in order to create and populate the database, and to develop queries, than to learn Base in this role.
In my opinion, Base has a steep learning curve largely because it forces you to learn and use proper "database normalization" and SQL in order to build functional Forms. Base does offer Python as a macro language, but you would actually want to avoid macros to the maximum extent possible in the early stages because macros (and by extension Python+Dabo) are so powerful that you won't feel forced to build your application on the best foundation. A poor foundation could lead to some show-stoppers and re-designs. A proper foundation is a "normalized" relational database and a good working-knowledge of the power and possibilities of SQL. Base Forms leverage that power using SQL-driven List Boxes and SubForms -- common concepts that will prove useful when jumping up to a free-form front-end tool like Python+Dabo.
The spotty Base GUI support for non-embedded databases is not always a bad thing because it forces you to learn some features of SQL. Other front-ends force this SQL-learning issue even more. Python+Dabo are not good tools for creating a relational database at the administrative or foundational levels at all.
With the foundation set, and some queries developed, you'll be much better equipped to embark on the unlimited front-end potential of Python+Dabo.
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases' |
|
| Back to top |
|
|
liherb
General User
Joined: 19 Aug 2011
Posts: 38
|
| Posted: Fri Dec 30, 2011 12:53 am Post subject: |
|
|
DACM you are great! I'm really impressed with your informative reply and very sure OOo/LibreO is definitely going to thrive just because of a group of friendly people like you.
What worried me is its transferability. You mentioned Base Forms, but we should admit that Form building is exactly the weak point of Base, isn't it? And what's adds to its limitation is that Form is not as easily portable as tables or queries(views). If we adopt Base to build our Forms, and later on when we want to "upgrade" it using a free form Python-based builder, those Base Forms are not transferable and we will have to repeat a lot of manual work, adjusting something here, tweaking something there, just in order to get it to work normal again. This non-transferability alone is a headache, let alone its spotty performance in non-embedded JDBC support.
| dacm wrote: |
Python+Dabo are not good tools for creating a relational database at the administrative or foundational levels at all.
|
Could you please elaborate a little bit more on why Python+Dabo are not good tools for this? Knowing the reason is definitely helpful to understand this whole picture.
Many many thanks! 
P.S. Does anyone know why Ubuntu does not ship LibreOffice Base by default? Is there any justifiable concern over that?
Last edited by liherb on Tue Jan 03, 2012 5:23 pm; edited 1 time in total |
|
| Back to top |
|
|
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Fri Dec 30, 2011 4:27 pm Post subject: |
|
|
| liherb wrote: | | ...Base and Python-based front-end builders do SERVE DIFFERENT PURPOSES...They are not overlapping but complimentary, with Base strong in laying (maintaining) the foundation and Python+Dabo strong in giving you more flexibility in Form building. Did I understand this correctly? |
Yes, although my comments concerning "spotty JDBC/ODBC compatibility" were primarily focused on the GUI-based tools Base provides for Table creation and Column property adjustments. However...
| liherb wrote: | | ...we should admit that Form building is exactly the weak point of Base...and later on when we want to "upgrade" it using a free form Python-based builder, those Base Forms are not transferable... |
Well yes, we should admit that Base is weak at everything related to database application development; it's no MS Access. And Base/Writer Forms do not transfer at all; Python+Dabo equivalents will require ground-up creation.
Base's strength is limited to adding database connectivity to other Office components like Calc and Impress. Adding a Query, or even a Form or Report to the mix is no big deal. But when you embark on creating a standalone desktop application with Base tools alone, you'll find it quite limiting. Even my point about learning database normalization through the inherent correlation to Base Forms (and associated SubForm structures), isn't apparent until you get deep into Form development. That's a hard way to learn the lesson on building proper foundations. And even after the foundation is laid, you'll need to build confidence in SQL's ability to extract and manipulate the data. Most users in these forums try to circumnavigate these issues by jumping into macros. Still others are driven to the epiphany that $80 for MS Access is well worth the investment -- as few Base users are sold on Linux or have a stake in the outcome of the Open Document Format (ODF) wars that motivate OOo/LibO developers. But you're a different case...
| liherb wrote: | | Could you please elaborate a little bit more on why Python+Dabo are not good tools for [building a relational database from the ground up]? |
You see, you're the first user, that I've encountered, to use Base as a stepping-stone to learning a programming language and framework in support of a database-driven application. I'm sure you're aware that the skills and knowledge required to 're-invent the wheel' as you leave the comfort of a GUI-based application builder behind are substantial. Frameworks like Dabo help, but you're no longer in a comprehensive, database application development environment like Base or Access. There's no GUI-based table-builder or column properties tool. And there's no GUI-based query-builder. Dabo's Form tools are strong but they require code tweaking in all cases (as far as I can tell). Reports are much the same; lots of getting your hands dirty with code.
So lets be clear. GUI-based application development will always be limited compared to free-form tools like the Dabo framework. However, GUI-based development is much easier for non-professionals and hobbyists. And the general knowledge gained through GUI-based tools is largely transferable to framework-based tools.
The knowledge you'll glean from these forums on things like List Box function, and populating a List Box through complex SQL, is transferable. The knowledge you'll gain from filtering cascading List Boxes using sub-queries (otherwise implemented as SubForms in Base) is transferable. The knowledge you'll gain from other examples such as searching by multiple Text Boxes using SQL %LIKE% commands will prove helpful. And my guess is, you'll find yourself using Base tools like the Query-builder to develop queries for your Python+Dabo front-end. But I'm sure Dabo has excellent support forums and third-party GUI-tools for such things as well.
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases' |
|
| Back to top |
|
|
liherb
General User
Joined: 19 Aug 2011
Posts: 38
|
| Posted: Sat Dec 31, 2011 7:38 pm Post subject: |
|
|
| dacm wrote: | | Most users in these forums try to circumnavigate these issues by jumping into macros. |
Hi dacm, do you mean most users will develop their own macros or they simply pick up some macros publicly available? I mean, if they develop their own, then it seems very little difference than learning a new language in order to implement some features; if they pick up macros already made public, then could you please recommend a place to find those gems?
| dacm wrote: | | And my guess is, you'll find yourself using Base tools like the Query-builder to develop queries for your Python+Dabo front-end. |
That's exactly what I thought. Do you see any problem with this?
I'm also very curious about how useful the "HSQL Database Manager" shipped in the package of HSQLDB 2.26 is. Is it supplementary to Base and provides some unique features, or is it just a very very minimalism/primitive GUI tool(that basically not very useful)?
Thanks. |
|
| Back to top |
|
|
dacm
Super User
Joined: 07 Jan 2010
Posts: 734
|
| Posted: Sun Jan 01, 2012 12:32 pm Post subject: |
|
|
| liherb wrote: | | ...if they develop their own, then it seems very little difference than learning a new language in order to implement some features; if they pick up macros already made public, then could you please recommend a place to find those gems? |
True. And the differences really become obscured when you consider that Python is included as a plug-in macro language for Base. And for that matter, I guess you could customize and compile your own versions of Base -- after all it is open source code. But short of extreme measures, the really noticeable difference between Base-GUI Form development and framework (Dabo) Form development is in the flexibility of the Form Controls. A Base List Box or Table Control (grid) is limited to the functionality and look-&-feel provided by the Base developers. This is not necessarily the case with a wide-open language like Python that enjoys several frameworks, plug-in classes, and the fundamental ability to develop or tweak Form Controls from the ground-up. It's a rather unlimited environment depending upon your time and talents.
For Base Macro tutorials and code snippets, see: http://www.oooforum.org/forum/viewtopic.phtml?p=432124#432124
| liherb wrote: | | Do you see any problem with [using Base tools like the Query-builder to develop queries for your Python+Dabo front-end]? |
No. Specifically, the 'direct SQL' mode of the query builder is relatively powerful. Commercial front-end tools offer more refined GUI-based SQL-builders in some cases, but Base is quite adequate for developing SELECTs.
| liherb wrote: | | I'm also very curious about how useful the "HSQL Database Manager" shipped in the package of HSQLDB 2.26 is. |
Base is not an optimum tool for administrative tasks such as implementing the database schema (particularly through JDBC/ODBC). Once you've bypassed the GUI by typing SQL commands, any general-purpose database-management tool will do. So as a general rule, always use helpful GUI tools such as the "HSQL Database Manager" until or unless Base proves easier. Base offers a minimal, under-developed, database-application development environment (in addition to its primary role of generating Office data source connectivity). It may improve in this secondary role in the future, but at the current development pace, expect it to continue to get worse before it gets better, and don't expect it to rival MS Access 2010 in this secondary role anytime this century.
_________________
Soli Deo gloria
Tutorial: avoiding data loss with Base + Migrating 'Embedded databases' |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
