Theoretically, our approach is general enough to be able to answer any SQL query. In practice, however there are many aspects related to the query processing that need to be solved. The optimization issues, for example, are more important than usually since two equivalent rewritings of the initial query can lead to completely different execution performances. In our project we used the option of complete shipping of one or the other tables whenever a table that is not directly queried through forms is used or when attributes other than name and title (that define the selection) are presented. However, this extra shipment can be avoided in some cases (such for example when that attribute is not used in an equivalent query strategy generated by the query optimizer).
Other aspects, such as handling general predicates that cannot be expressed as a sequence of = and like operations, are not enabled in our system, due to the considerable extra amount of work they require. Even the translation of complex patterns that SQL can support (given the special wild cards) was not addressed in the project. However, these aspects can be solved in the next versions.