Many of our users wish to see all the existing records of collection objects when they start working so that they can go to the last ones and control or update them. Of course these records can be obtained by a query, but for many users this is too complicated (actually the queries are not understood by many users who do not know what a relational database is).
So it would be good to have in Record Sets a kind of dynamic Record Set button that will show all existing records for the Collection Object form.
Hi @Schuchert,
We have had users request similar functionality before! I think itâs a really interesting idea to have the ability to view all records in a table without having the knowledge of how to build queries.
We have a couple of feature requests on our GitHub repository that ask for a similar functionality.
Then, would be nice if we could share some queries
@maxpatiiuk has reccomended the following workaround in the past:
The current workaround for sharing a query is:
- Open a query
- Copy the URL from the address bar
- Send it to another user
Then, a set person can execute the query, or clone it in order to make changes.
Another institution has requested a âData Viewsâ option!
âData Viewsâ menu (#2047)
We are proposing a new menu item called Data Views or similar which offers lists of certain data elements in a scrollable way like the output of an unrestricted query. This would remove the need to have a suite of standard simple queries for a combination of some Interactions and Data Entry items like loans, borrows, permits, agents etc., and would make access to the data faster (fewer clicks).
Do either of these options sound like a good solution to you?
Thank you for sharing your request!
yes, this would be great and make Specify more acceptable for our users (who often complain that Specify was built for software specialists but not so for collection managers; these users previously used Filemaker solutions and wish to have a similary intuitive user interface).
If such a view of all CO forms can be implemented, why not also give a find function for the catalog number ? The find function would search and go to the requested record.
1 Like
I would like to suggest that, in fact, the Sp7 web application is already simple enough to adequately address these needs. To return all the records in a table, all you need to do is add a single field to a query and run it (then select all the checkboxes of the results, using the shift key, and âbrowse in formsâ). I have a small amount of experience in applications like FileMaker Pro, RapidFile, DBase etc. and from my experience there has always been a requirement for at least some knowledge of a database schema.
There is already a quick and easy way to search for a catalogue number, using the search box in the top right corner. (You type the number, hit enter, then click on the result to see the form).
I would also like to suggest that there is a maximum number of results that can be useful to a human user. Most databases are going to contain more than 1000 records. But even paging through 1000 records is not going to be a meaningful way to interact with information. I guess it depends on the specific question, but usually, in the context of a natural history museum, you need to page through 10 records, e.g. to correct errors. This requires you to limit your search to return only the relevant records.
I am quite surprised that there would be a request to return all records. Perhaps I need a more detailed explanation of the use-case.
I thought that I would contribute to this discussion because I feel that the Specify interaction design is very good and easy to use/learn, and I wanted to record this.
having had the wish to see all CO record with one click from several users (including me), I still think it might be useful. Itâs just reassuring to see hat all records are still in the database.
Using Queries in Specify is really difficult for people not using it every day. They have a hard time to find the fields or to know in which table they are.
The UI for Queries in Specify 7 is even more complicated and even for advanced users like me difficult to use
I had a user who preferred to create a Dataset for the records he was working with and then use the âJump to Recordâ function to retrieve the records he wanted.