How TSQL.APP works

Two databases

Every application is a pair: the business database holding your tables, views and procedures, and a project database holding the application definition — cards, fields, actions, children, tasks and users. Business data and application metadata stay cleanly separated but travel together.

Cards are screens

A card names the view that supplies its list data, the writable base table behind it, its primary key, and an optional reducer — a WHERE clause applied to every query on that screen. Several cards can present the same table in different ways for different roles.

Actions are T-SQL

A button is a script. It runs server-side with the current record and user in scope, can call any procedure, open a dialog, write to any table, and refresh the screen when it's done.

Compiled caches

The framework pre-compiles the select statements for each card, so runtime rendering is a straight query rather than dynamic assembly.

The framework is built with itself

The screens used to manage cards, fields and actions are themselves cards. Anything the platform can do to your application, you can see it doing to its own.