Master-detail form testing revelations.

Master-detail form testing had its own surprises for me as I compared its organization through different present-day web databases.

To make the investigation of readers less time consuming I summarized the results in the table below and tried to put my findings in a clear-cut way. Anyway, you can specify the way of implementation in each tested service looking through the step-by-step explanations.

In the table below you can check products I considered eligible to appear in master-detail form testing:

Product	Results	Impression
Dabble DB	Possible, but with the shortcomings of the system.	There were too many "peculiarities" of implementation which caused a number of difficulties.
TrackVia	Not possible. There is no way to build master detail form.	It seems to me that currently Track Via program is developed for single table/database applications.
QuickBase	Possible, the set up is pretty easy.	The system handles the issue, the only drawback: you can’t add/edit items on one and the same screen with header.
Coghead	Possible. Two ways of set up are suggested: Local Grid and Linked Grid	None of given variants is an ideal way of this function implementation. Even though I managed to set up everything.
Zoho Creator	Not possible. Zoho offers to use Deluge Scripting instead of master detail form.	Puzzling the user with too cumbersome alternative, which doesn’t solve the problem.
TeamDesk	Possible, fast way of implementation is offered.	I liked the system capability to handle a lot of implicit work on its own.

So, hopefully this sneak peak outlines what to expect choosing one of the listed products.

Pinnig hopes on Zoho Creator master detail form

Having tested Zoho Creator functionality for several times already I am still expecting to implement my next task from the first shot, because I do believe this product is capable of resolving such issues.

This time it’s checking master detail form function on the same example as I did before testing product Invoice (master) and it’s Items (details). I easily created the app and 2 tables (Invoice and Items).

This is how the Invoice looks like:


And Items:


I managed even to merge these 2 tables using Lookup Field and added Formula Field, what enabled the calculation of Total item.


This is where we are done with the good news. Unfortunately Zoho Creator doesn’t have any mechanisms for master detail support and offers to use Deluge Scripting, if the steps of its implementaion is of any interest for you can take a look at this.

Frankly, I am not a fan of this Deluge Script. Besides, to go this way one should know HTML and Javascript, and to my opinion it’s not a case for business user.

The thing is it's not worth taking so much pains and above mentioned steps in order just to get 2 links, which don't solve the given task well.

I also couldn’t find out how to calculate Grand Total of all Items in the invoice. I suspect, it also requires Deluge Scripting.

TeamDesk master-detail sets an example

Taking decision based on facts is the only way not to give your money up for lost. I believe only this can lead to reasonable choices and give a hand in taking the most from the products.

In continuation of my test of master-detail function of QuickBase, Coghead, TrackVia and Dabble DB I decided to finish trying TeamDesk capability of managing this.

Using the same example with the invoice as I did in other tests I created a simple app, so you can check out the organization of TeamDesk master-detail:


Actually, the set up was easy enough, I managed to create 2 tables: Invoice with Company and Date columns and Items with columns Description, Quantity and Price. After that I created Total formula column in table Item:


I think there won’t be any problem handling formula columns, if one have ever worked with Excel or studied math at school.

To create one-to-many relation of these tables my next step was linking of Invoice and Items:


What I especially liked in TeamDesk it’s creating relations, what gives an opportunity to automatically handle all boring work you should do to have a full-fledged master-detail, namely to create reference column, choose how to display details, to set the way of how to select records from master:


These operations are not difficult, but the fact the system can accomplish it for you lets focus on business logic of the app, not on the primitive operations. You just give it a final touch creating Grand Total summary column that calculates the total of all invoice items:


And it’s done. Not bad. Finishing my coverage of TeamDesk I'd like to mention how master-detail works from the stand point of end user and what peculiar moment should be taken into consideration:

• One can see on the first screenshot layout that master and detail are displayed on one and the same screen, but on different screens when editing.


• The button "Add Similar" doesn’t add a new invoice with items, but just creates the new empty copy.


• As well as Delete button in the invoice table don't do anything with items.

Conclusion:

Frankly, despite these moments TeamDesk proved to be a powerful mechanism for master-detail implementation and I especially liked the system capability to handle a lot of implicit work on its own what speeds up the process of getting the working app prototype.

If you manage to tune master-detail of TrackVia let me know!

Dealing with web-based systems I keep on looking for a so-called "holy grail" of SaaS solutions. Ok, not a holy grail, but at least that one, which would correspond to at least 40% of "we are the best out there" crap. Hopefully, I will manage to do that before the World Ocean dries out.

So, let’s get down to business and check the organization of master-detail relation of TrackVia. I won’t deviate from previous algorithm of testing, as I did it with invoices and items of Dabble DB, Coghead and Quickbase. This is how the invoice looks like:


And here you can check the creation of Invoice Item:


I couldn’t find an option to display my invoice with items on one and the same screen and to calculate Grand Total of all invoice items and reflect this sum in the invoice.

So I decided to ask TrackVia support to give me a hand at this and this is what Ed Dunigan offered:

"With TrackVia, you can edit parent and child records at the same time through a custom view. You would create a view and denote the fields you want included in the view. You would then select to display the view in Edit All where you can then edit all fields desired."

I took Ed’s advice and built this custom view, this is how it looks like in Edit All mode:


Summing up:

What can I say … This option is definitely not enough for master detail support: the user doesn’t edit items of all invoices simultaneously and the very point of master detail is in displaying the data as the comprehensive whole, I mean users want to display invoice with items, not separate titles and positions.

It seems to me that currently TrackVia program is developed for single table/database applications, let alone the possibility to create relation between tables and any calculation of this relation is very limited.

Coghead master-detail. The matter of choice.

Coghead has two ways of master-detail form organization: local grid and linked grid. I contacted Coghead support guys to find out which way is better for master-detail organization. So, I am going to follow the recommendations and test both variants.

This is what Jonathan McKibbin suggested on local grid:

"Local Grids allow you to add something similar to 'sub records' to a single record. These individual sub records are only displayable in the form of the record that they belong to.

An example on how to create a calculated field which sums the column of a local grid can be found in Tutorial 3: Section 3.

The advantage of this approach is that you can easily add, edit or remove rows from the local grid. The disadvantage is that it is more difficult to report on the local grid and you would need to create calculated summation fields and use those fields in the collection tab's view."

The explanation is really thorough so I created an Invoice using local grid and this is how it looks like:


I easily created a calculated Total field for each item row and calculated summary field Grand Total. In general editing works quite well and the program calculates everything on the fly, but I think the local grid is better to use in case you need to save several one-type objects within the record, without further processing, such as many addresses of the company or several phone numbers. If you need to build any reports based on this data in the future I think the access to the detail only through calculated summation fields is obviously insufficient.

As far as I am through with local grid, let’s take a look how linked grid functions.

Jonathan offered to apply the following with a detailed explanation:

"Linked Grids allow you to display a list of records from another collection. One of the most common use cases is to display related records in a parent-child relationship between two collections. Since the child records are in a different collection this would give you more control over reporting through both views in the child collection or through additional linked grids in other collections.

An example of how to create the parent-child type relationship between collections can be found in Tutorial 2.

The advantage to this approach is that it gives you greater flexibility when it comes to reporting. You can create views within the Items collection or use record tabs to create a dashboard-like interface for reporting. The disadvantage to this approach is that it is a bit more difficult to set up and that you would have to navigate to the Items collection, by clicking on the row of the linked grid in the Invoice record, in order to edit or delete the row."

This is an Invoice if use linked Grid:


Despite the fact its’ structure looks so much alike to the local grid (except for the opportunity to add Items at once), frankly, it was not so easy to create a parent-child relation.

The very process of Invoice and Item table creation was not difficult, but my next steps of relation creation were not that simple:

1. I used Link widget for Item edit form to make it possible to refer to a particular Invoice.


2. Default grid widget displays all Items to Invoice edit form, so I had to set an additional filter to enable the Item selection of a specific invoice.


3. To create Items from selected Invoice and have them automatically linked one should create Custom Action.

Conclusions:

Its nice to have two different mechanisms for master-detail organization, but none of them is an ideal way of implementation.

Local grid is a way too primitive for anything but just gives the opportunity to the customer to enter a variable number of attributes (phone numbers, for example) and Linked grid along with custom action allowed me to tune everything I actually needed, I had such an impression I used a sledge-hammer to crack nuts though.

A “but” of Quickbase master-detail

My next testing target is Quickbase. Using the same invoice sample with items like in Dabble DB test, I create two tables with needed fields and tie it together through one-to-many relation.

This is how the invoice looks like:


I seem to have liked the opportunity to easily add Total (Quantity*Price) calculation for each item and calculate Grand Total of all items through summary fields in relation.

One should pay attention: Header and Items can’t be modified simultaneously. For example, creating of new invoice I was offered to save the Header at the very beginning, though everything looked so as if I could add Items at once:


I think such an interface misleads the user. This is how Item add/edit function looks like in invoice:


Summary:

Quickbase master–detail form is easy to create and it works quite well, if you are ready to accept you cant add/edit items on one and the same screen with header.

Dabble DB master-detail and duplicate records handling.

In this post I am gonna cover how Dabble DB master-detail works and how to handle duplicate records.

Having built a simple invoice application I created two entries.Invoice (master) where I will save the header:


And Item (detail) for storage of invoice items:


This is how invoice editing looks like:


Pay attention to the type of difficulties I as the user faced (the peculiarities of Dabble DB master-detail implementation):

• Dabble DB doesn’t reflect the detail in the grid form with column names;


• I couldnt calculate and display the Total column of Items on the same screen;


• Failed to find an option to calculate invoice grand Total on this very screen;


• Couldnt edit invoice Item on this screen, cause the system redirects me to another page.

Let’s take a look now which means are there for search of the duplicates. Dabble DB has no built in tools for duplicates search. As I’ve looked through Dabble DB forum, the support team offers to do following things:

"The easiest thing is probably to group the entries by a column that should be unique. Any unique entry should be a group of one, while duplicates will be grouped together. You can then use the Actions menu to merge all groups, producing only unique entries."

So, let’s follow the advice and check what happens while doing this:


This is what I’ve got as I pressed Go:


When testing the function the system takes first master record and all details from deleted master records are transferred to it.

The good news is the system merges detail records to the new master.

But! The user can’t control which master to pick as a base and define the right field combination for resulting master record.

Master-Detail Form. Let’s check the way of its organization!

I’ve got to figure out the best way of the implementation of such an issue now:

One of the most common types of form in database applications is "Master-Detail" form. "Master-Detail" form display a master row and multiple detail rows within a single page. With this form, users can query, insert, update, and delete values from two tables.

I want to find out and compare which ways for master-detail forms organization offer present-day web-databases. So one can define what is the killerest solution.