The half is done finding and merging duplicates in TrackVia

Lately I’ve tested the capability of powerful services (I laid my eyes on QuickBase, TeamDesk and Dabble DB solutions) to find and merge duplicates.

Continuing to figure out of how it’s done through different systems, the next service I’d like you to take a look at is TrackVia.

To clear up how the things are organized in TrackVia I will use the same database as I did while checking TrackVia master-detail function.

This is my initial data:


The good news is TrackVia has a built-in tool for finding duplicates:


After that the system offers to proceed following actions with detected and marked data:


Unfortunately there is no possibility to merge records, that’s why the user must manually redirect Items from invoice and delete not necessary records.

Conclusion:

In conclusion I’d like to say that TrackVia find and merge duplicates option functions well and 50% of work is accomplished. What is left for developers is to put the finish touches on the other 50% and add merge option.

TeamDesk dependent dropdown. Just do it.

Even though I have just begun to test Dependent Dropdown functionality the results got pretty interesting by now.

Having checked the things with QuickBase dependent dropdown and being pretty puzzled still the only thing I can state is you can never be sure until you try the service through real life problem.

My position is not to take anybody’s word for it, but to check it all by myself!
In this post another example of how it can be handled through TeamDesk.

Let’s take the same example with States and Cities. So this is how initial data looks like:

States:


Cities:


Create another table, Customer, for example, and set relations between Customer and State, as well as Customer and Cities for dropdown testing.

This is how Customer is added without dependency setting between States and Cities:


To create a dependency between State and Cities in TeamDesk one should just take one simple step. Add in relation of Customer and City match condition so that chosen State of the customer should agree with the State of the selected city:


Now TeamDesk can dynamically filter the content of the dropdown and City selection when you add the Customer and works as needed:


Conclusion:

Easy done. It should be noted that it’s also simple to add any quantity of such dependent dropdown of customer form and tune its dependency according to city or state or any other field in table Customer using such principle with relation and match condition. And by that all dropdowns will be dynamically reloaded according to set match condition. Good job.

QuickBase dependent dropdown. The art to place shortcomings as benefits.

Each and every time I test the service I am never sure what to expect, cause you never know until you try.

So, what does the system hold for the user this time?

It’s really a tricky thing I must say.

As I mentioned before I will test a dependent dropdown through States and Cities. At first let’s create tables of states and cities and set a relation between these tables in order to relate states to cities. Take a look at the initial data:

States:


Cities:


Now I can check out variants of dependent dropdown realization that QuickBase offers. Unfortunately QuickBase doesn’t support conditional dropdown function, so the developers offer such alternatives:

Recommended way of implementation: to select from the final dropdown (in our case it’s Cities) and to use record picker rather than a drop-down menu for selection, as it gives a possibility to search. And after saving through lookup fields get the State from relation. This is how the city selection looks like:


And the record after value selection:


For better understanding of how it is done check the peculiarities of set up specified in this article.

Not recommended way: If you want to get actual dependent dropdown lists in QuickBase you’d better be a wizard of HTML and Javascript. The details of how it is done are described here. I totally agree with QuickBase here and don’t think that a common user will choose this way if he is in his right mind.

Conclusions:

The dependent dropdown alternative that QuickBase offers for the specific case with State and Cities solves the issue not so bad. But the goal of my testing is to show users the level of flexibility of different systems.

I can understand why developers try to represent any restrictions of the system as its peculiarities or even advantages. I was puzzled a bit with this statement:

"There is a better way to accomplish this than using dropdown lists whose content depends on the selection"

I think that suggested variant is not an appropriate solution in many cases. For example, there are several dropdowns which dependend on one dropdown?

So I my point is QuickBase doesn’t support dependent dropdown at this stage. Anyway the user decides if the offered alternative is good for him.

Kicking off with a Dependent Dropdown. Check out the way of Coghead!

Finally I’ve got a chance to test the support of Dependent dropdown through different systems, kicking off with Coghead.

Each product will be tested through a simple pattern. I want to set up the selection of the city depending on the state.

This is my initial data with the list of states:


And the table with a list of cities:


So, to get what I want I create the table Records firstly for a dependent dropdown set up in order to filter the particular State in dropdown, so only the cities of this specific state were selected.


To secure this I added 2 link widgets and installed the corresponding link collection in each one. Also I added Filter for City, where I indicated the condition that the selected on the form State is equal State from Cities collection. More detailed instructions of set up and how it’s done you can find here.

As I’ve managed to tune needed options I can show you now the Dependent Dropdown in action:


Drawing a conclusion:

Coghead supports dependent dropdown well. I managed to do what I wanted. The only problem may arise when you set up the filter, because of the a bit complicated structure of the condition creation and resulting formula State=State also doesn’t clear up what is actually this condition all about.

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.

Adding new users smartly

Utilizing a web-based system sooner or later you’ll have to decide how many additional licenses you need, and how many you can actually afford to buy.

I guess this issue concerns many people out there, especially now, in times of all this mess with a financial crisis and stuff. So it won’t be out of place to check which vendors offer solutions which are not too heavy for the wallet.

Oftentimes the user of the service has many clients and wants to grant them access to the web-database as well, but can’t afford buying the same quantity of licenses or there is simply no opportunity for interaction when the prospect can't be registered in the system in advance.

Check out my findings in upcoming posts and save some time choosing the most appropriate option.

Simultaneous record editing test results

Let’s get back to summarizing results of products I’ve tried in regard to solving definite tasks.

Simultaneous record editing by multiple users this time.

You can quickly overview my conclusions put in a lucid manner in case you just want get straight down to business and just clarify the value of each service concerning simultaneous record editing.

Having checked the handling capability of 6 products, users can decide WHY exactly chose one or another service, skipping all the "how-to".

Product	Results	Impression
Dabble DB	Dabble DB doesn’t have any support of simultaneous editing at all.	The user changes are just substituted by the changes of the other. Double check all alterations!
TrackVia	TrackVia developers applied another method of simultaneous record editing. It is substituted by the complete report of record changes.	To my opinion the detailed history of changes is of a great help for tracking each record editing, but eventually it can bring the data into a total mess.
Zoho Creator	No possibility. It’s the concern of the user how to resolve the situation of data overwriting.	Obviously, Zoho developers didn’t pay much attention to such an issue as simultaneous editing and problems with the data consistency which may arise if it happens.
Coghead	The problem is handled only partly.	Offering just to press Yes/No doesn’t inform properly about record changes. There is no way you can understand who has changed the record and the system doesn’t indicate edited fields.
TeamDesk	Properly solves the issue.	This is the only system of all tested ones, which supports this mechanism for file attachment.
QuickBase	QuickBase developers had taken into consideration the problem of simultaneous record editing.	When editing the records all changes should be marked, not selectively as it is now, without even mentioning that I have lost my data change once.

Surprisingly, only several systems really paid attention to such function as simultaneous record editing by multiple users, despite it happens pretty often I’d say.

Anyway, at least it’s clear what to expect choosing one or another service.

TeamDesk running total impresses

Must say, it was a bit unexpected for me to get to the point at once in TeamDesk blog how one should calculate a running total.

TeamDesk guys offer to apply the same method as by finding duplicates.
Lets try it out.

So I created the app in TeamDesk for my experiments:


According to the example I created many-to-many relation of mine with match condition which filters needed records and adds required column for sum calculation of these records:


This is calculated running total in TeamDesk:


The best thing is that in TeamDesk running total is calculated for each record and is added according to new record as a new field, what allows using this value in other reports, like these:


Conclusions:

I am satisfied with the results. Running total calculation through TeamDesk is really easy. The Setup is maybe not that simple as in QuickBase, but a way better than in Coghead. I would like to make a special mention of the opportunity to use calculated running total in other reports.

Lets get to the point and sum up starting with large data volume

Having tested product capabilities of handling various tasks I think I can drop few words of what I’ve come up with concerning each discussed problem.

I don’t want my readers to get lost in a bunch of my posts, so just in order to simplify skimming the blog I will sum up the final results of each testing issue.

If someone wants to simply skip all "why" and step-by-step explanations but just find out the result, for those I will write a concise final review of each item.

Let’s start with tests of capability to handle large data sets. I haven’t even planned to test 7 services, but it turned out I was that curious.

Results of Large Data Set Importing (20 000)

Product	Results	Impression
Dabble DB	First try failed, a bit later support guys fixed the bug	Didn’t expect that initially the developers had not assumed this need of users
Coghead	I managed to import my data. In general after the completion of importing I had no problems with data navigation, filters, searches etc.	20 000 records is not that large volume to scare off Coghead. The settings of the program puzzled a bit.
TeamDesk	Positive result. All data was easily imported. TeamDesk had no problems searching the data and building reports of such data volume.	It seems TeamDesk system handles large data volumes easily, but some functions are to be tuned yet. Implementation process was not that cumbersome.
QuickBase	Proved to be quick importing 20K. Successfully.	In general the approach is pretty holistic. It was simple and didn’t require any additional steps.
TrackVia	The simplest way of importing such data amount.	The guys resorted to cunning: the moment where other offered to define field types and name them is implicitly transferred to Excel.
Caspio	The import process ran pretty smoothly. All data imported.	I have met my expectations, but I have an impression that the system is developed rather for more tech savvy users, than for non techies.
Zoho Creator	First shot completely failed. The second one was successful.	In a couple of days Zoho support changed it and added missing functionality. But it didn't feel like finished and mature product.

So, this is what I’ve managed to find out. Make a reasonable choice!

I started to twitter

To make a better use of what I am doing in my blog and let more people know about reviewed products I decided not to pass up the opportunity to create a Twitter profile.
Besides, a lot of folks are twittering now how actually good the Twitter is, so I am there too.

Feel free to follow!

How much effort is needed for running total in QuickBase?

Sometimes it’s quite a surprise to find a system known as powerful not capable to handle a simple task and vice a versa. It happens that not so often mentioned service copes perfectly with the problem. But one way or another if the service has a big name it has to be something to it.

Let’s see what happens in QuickBase while running total calculation.

This is my initial data and how it looks within the system:


I managed to define how to implement my task right away. To get Running total in QuickBase is possible through summary report, thank to option of how to display results:


This is what I have got:


So you can drilldown just by clicking the specific date and take a look on the received in the given period amount:


Conclusion:

Without further ado I can tell that QuickBase offered the simplest method of running total calculation among all products I've tested before. If you are ok with the way the summary report displays results to user, of course.

TrackVia running total is up in the air

As I've made up my mind to test running total of TrackVia I decided to contact their support team in the first place in order to spare my time and clear up things at once. My previous experecince just confirms it is the right thing to do.

Actually, I had already tried the system capability to calculate running total, with no success... So I was kinda hoping it was me, not the service.

The answer of Matt Strenz, the support representative of TrackVia almost made my day:

"You can easily get a running total for any field in any view using our statistics. To so this you just select Statistics from the Format dropdown list in the upper right while looking at a view. You can also set a view while editing it to show in Statistics mode by default on the Display Options tab. Using this you will get a total, maximum, minimum, mean, etc for all number fields in the view.

For Example. If you have a view that shows 10 different sales and you have a field storing the sale amount you can easily pull this into statistics to see what is the total of all sales. Please let us know if you have any other questions or comments!"

But I am telling you "almost" because it was actually not the explanation I had asked for.

My aim was to create in TrackVia such a report through which I could build a diagram of running total change of definite time value. This was my point.

I just couldnt help but give Matt a call to explain what I needed. In addition I sent an e-mail with an example of what I was trying to implement.

I was almost sure I was close to show you how it actually can be done.

But after a while Matt e-mailed me again:

"In looking at what you linked to in your previous email we now understand what you are looking to do. We do not have the ability to do this in TrackVia currently but we will log this as a suggested enhancement."

I hope you'll manage to handle this, guys.

Is there “An unbiased point of view” at all?

So many people out there talk about neutrality. Actually, I take it pretty seriously too, but…

Working within different web-based services one way or another you get attached to the best ones...

I mean, if it’s clear cut which solution rocks in this specific case, naturally, you want to praise it and say “Attention, guys! This is it!”. But each and every time I am trying to contain myself from doing that, no idea how well its done though.

Sometimes it’s quite an issue to be neutral and just state something. Let’s be honest, if while testing one finds the product to be really something (at least in the specific case) and can really add value to the app is it wrong to recommend it?

I don’t know to what extent I manage to keep so-called unbiased position, but I do my best for this. My point is if the product is good readers are smart enough to recognize it and decide for themselves what to do.

My job is just to show them how it works in practice, solving the given task.

Coghead interestingly handles running total calculation

Personally I consider the opportunity to build a running total within the program as a good test in order to understand if the system has powerful tools for report creation.

How is it done in Coghead?

Before I start I would like to thank Jonathan McKibbin with Coghead support, who helps me to push things on in a right direction.

So I created a simple table with two fields Date and Amount. The thing is I try to calculate a running total for each record (Date).

Firstly I added Running Total aggregate column that calculates summary of Amount column of Sales records with the same or earlier date to the current date.


One could say this is it, there is nothing left just to calculate a running total, but the principle of working within Coghead doesn’t support dynamicall column calculation displaying the data, but all calculated and aggregate columns are processed and saved just on one occasion in the database.

On the one hand it influences positively the performance displaying the data, but it takes many pains to keep the data in a consistent state and now I will show you what I mean:

It is necessary to modify Create, Update and Delete actions, so when you update one record the other related records will also be updated. To make things easier, let me show you what I did on the update action example. In Update action flow I had to add following steps:

Firstly, I had to find all records with Date greater or equal than Date of the record being updated (stored in the Input variable) using a Retrieve Record step. Then, using a For Each loop to step through each record found in the search, you will need to update the record by using a Perform Action step to update the record.


Similar steps one should take creating and deleting a record. This is what I have got as a result:


Conclusion:

I managed to calculate a running total in Coghead, but I think that setup is not that simple, especially actions. Such implementation can also contain a potential problem of performance and deadlock for it’s quite an issue how this solution with a constant multiple record update will work with a large volume and in case multiple users edit records.

Why should a running total metter to Dabble DB?

I was a bit puzzled to find out that some issues of system functionality bother me, but not the users of the vendor. Trying to figure out the possibility of running total calculation through Dabble DB my decision was to ask the support how this can be done.

Andrew Catton explained how the things are:

"We don't have this at present (honestly, it hadn't yet come up in talking to your users). One variation on this that has come up, and we do support, is the ability to group dated entries by month, with running subtotals.

If we do see demand for this, we'll certainly considering finding a way to add it.."

My data looked like this:


And the report with group entries by month, with running subtotals:


So I will keep you informed if anything changes. I guess sooner or later Dabble DB developers will find this issue worth a solution and show the way to calculate a running total. We will see.

Simultaneous editing. Zoho, show them all!

I am still recovering from the impression of what Zoho support can do and can’t wait any longer to test another system feature - simultaneous record editing capability.

I’ve chosen a predesigned app Expense Tracked form their Marketplace and added one record in order to check if I could do it through 2 web-browsers as I did before.


After that I opened this record for editing in Firefox and changed Data and Payment method fields:


In IE I changed Amount and Payment method:


At first saved it in IE without a hitch:


Let’s save it in Firefox now:


What do you think happened? Everything was also saved with no question or warning.

Conclusion:

Obviously, Zoho developers didn’t pay much attention to such an issue as simultaneous editing and problems with the data consistency which may arise if it happens. My point is it’s the concern of the user how to resolve the situation of data overwriting.

But I can’t be that sure the things won’t change, for this feature can see the light of the day shortly, as our previous showcase proves.