Tap Forms – Organizer Database App for Mac, iPhone, and iPad › Forums › Using Tap Forms › Removing items from a collection
- This topic has 8 replies, 4 voices, and was last updated 3 years, 11 months ago by Doug Bank.
-
AuthorPosts
-
January 17, 2021 at 10:02 AM #43202
Doug BankParticipantWhat is the best way to document removing items from a collection?
Let’s say I have a collection of items documented in a Tap Form. I sell one of the items. I don’t want to delete the information, but I don’t want it to appear in my “inventory” either. Should I have one master form with all the items I have ever had, but use different layouts to show items I still own vs items I no longer own OR should I move the record from a form for items I own to a different form for items I have sold or given away?
If I keep everything in the same form, would I be able to control which records are shown on the list on the left or does it always show every record in the form?
If I don’t keep everything in the same form, is there an easy way to move a record from one form to another? It would be great if you could drag a single record from one form to another, but that doesn’t seem possible.
It does seem like keeping everything in the same form is the best solution, but I haven’t attempted custom layouts yet, so I’m not sure what things are possible.
January 17, 2021 at 11:43 AM #43208
Daniel LeuParticipantI keep track of my artwork using TapForms. When I sell a print, it is marked as sold with additional information like buyer and price. Then I use a few
Saved Searches
to list only sold or available prints. This way all my prints are in the same database, but I only list the once I’m interested in.January 17, 2021 at 9:08 PM #43225
BrendanKeymasterHi Doug,
As Daniel mentioned, Saved Searches are really the way to handle this situation. You can create as many as you like to filter your records to show only the ones you’re interested in seeing at that moment.
Some people have asked how to move records from one form to another, but Saved Searches are really designed to be a better workflow than moving records around.
Thanks!
Brendan
January 18, 2021 at 9:27 PM #43244
Doug BankParticipantBrendan,
This is kind of stupid, I suppose, but… hmmmmm, how to describe my “problem”?
The basic problem: I want to catalog all the specimens I own. On top of that, my son wants to catalog all the minerals we own (A specimen is composed of one or more minerals)
I have 4 associated forms. There is the Specimens form, but each record in that form has links to the Minerals form and might link to other forms as well. If I mark a specimen as sold, it doesn’t break those links. However, I was using that information to keep track of how many minerals we own. If I share the information both ways – so that the Minerals form knows which specimens contain each mineral – then I presume that the Minerals form can also see if that specimen has been sold. However, the information is in that little table on the form. Can information in that table be used for calculations elsewhere in that record?
For example, lets say I have one and only one specimen that contains gold. I sell it and then mark it sold on the Specimens form. The minerals form still shows the specimen because it is still in the database. From the Minerals form point of view, I still have it. However, if I could calculate some field value based on the information back in the Specimens form, then I could remove Gold from the list of minerals that I own.
Does this make any sense? It’s kind of like I want to be able to generate a report that lists all the minerals that I currently own as opposed to all the minerals that exist in the world or even all of the ones that are in the Minerals form.
I’m sure I am making this more complicated than it needs to be. Sorry.
Doug
January 19, 2021 at 1:42 AM #43246
BrendanKeymasterYou could display the flag or field that indicates you no longer have the mineral so that when you look at your Specimens form, the mineral shows that it has been sold, even though it still shows up in the table.
January 19, 2021 at 10:15 AM #43247
Doug BankParticipantI agree that there are ways for my brain to process this, but if I want an accurate list of minerals we own, is there a way to do this programmatically?
I’m guessing not because I can’t even see those fields (the linked ones or the field that holds them) in the the search interface or in the fields available to equations.
January 19, 2021 at 3:33 PM #43249
BrendanKeymasterThat’s correct. The Saved Search mechanism doesn’t traverse down into relationships.
If you want to do searches based on relationships then you need to write a script that extracts some information from the relationship to appear on the parent form. Then create your search based on the values in the parent form.
January 19, 2021 at 8:42 PM #43255
Sam MoffattParticipantYou could create a count field that traverses the link from Mineral to Specimen and just counts how many have the flag or not and then use that to create the search based on if the count of specimens on hand is greater than zero.
January 20, 2021 at 5:29 PM #43260
Doug BankParticipantI figured (or possibly stumbled into) a solution. I noticed that equations on the Minerals form can see all the fields on the Specimens form.
I added a field in the Specimens form to indicate whether or not the specimen is owned. That’s easy now, since I own all of them. On the Minerals form there is another field that indicates whether the mineral is truly a mineral (for example, ruby is not a mineral, but corundum is).
It took me a while to find a syntax that worked, but I ended up with an equation that says
IF (Mineral? * COUNT(Specimens::Own?) ;1;0) (basically, if it isn’t a mineral or the count is zero, then the result of the first part will be zero, so don’t count it)
I tell the field/form to use a Total summary calculation, and then I get a count of how many minerals we own in the catalog.
(Is there a way to put comments in an equation, or should I just put them in the description?)
-
AuthorPosts
You must be logged in to reply to this topic.