MarkShnier__YouQrew LegendJoined 7 years ago9046 Posts1264 LikesLikes received286 SolutionsView All Badges
ContributionsMost RecentMost LikesSolutionsRe: Pipelines - Connected Table Refresh I was not aware they were to save the replication ID. But it's actually really interesting that the Community Forum likes this answer as using an unsupported technique. I was not aware they were to save the replication ID. But it's actually really interesting that the Community Forum likes this answer as using an unsupported technique. I do know a client acquaintance where they were forcing a refresh every five 5 minutes on a large table. They ended up getting into a huge fight with Quickbase as Quickbase said they were abusing the platform, so basically Quickbase told them that they're not allowed to do that. Re: Bulk Record Creation (User Defined # of Records) OK, great that you got it working. But if you're looking for some real fun and are willing to invest five minutes, try duplicating your pipeline and hack away everything except the trigger and the search step. Then insert a step after the search for import to Quickbase. I think you'll find that find that it runs about 10 times faster. So in a worst case if you had 500 suites, I bet it would take way more than a minute to complete your way with the loop. But I'll bet the Import to Quickbase isn't really sensitive to the size of the number of suites being created and will complete in about five seconds. It also saves you the set up of creating the bulk upsert and then they add row step and then the final Commit. So in future Pipelines you build, it seems simpler to just go directly to the Import to Quickbase directly after the Search. Re: Bulk Record Creation (User Defined # of Records) There is more than one way to do this, and the pipeline Ninja Jinja will have fancy methods with loops that count. but they will probably run slowly and be too technical for me, at least. Here is a fairly low tech solution, which assumes that it is unlikely that two users will be doing this at the exact same time. Create a Helper table called Suite Helper with all the possible values for the child records imported into a field called [Counter], so maybe import an excel sheet from 1 to 1,000. Create a single record table called Suite Count Select with exactly 1 record in it. It wiull be [Record ID#] = 1 Lock it down so no one, even the admin, can add or delete. Create a field on that record called [# of Suites] and another for [Record ID# of Building]. I am making the assumption that the ultimate Parent table for the children will be Parent Table is called Buildings. Create a relationship where 1 Suite Count Select has many Suite Helper with a formula reference field on Suite Helpers with a formula of 1. Lookup the [# of Suites] and the [Record ID# of Building]. Create a saved Table to Table Copy to copy records into the Child table from Suite Helper and map the [Record ID#] (lookup) into [Related Building], and set the filter where the [Counter] is less than or equal to [# of Suites]. Make a field on Buildings for [# of Suites] Now make a Formula URL button on Buildings. var text SetTargetBuildingAndNumberToCreate = URLRoot() & "db/" & [_DBID_SUITE_COUNT_SELECT] & "?act=API_EditRecord&rid=" & "&_fid_6=" & [# of Suites] & "&_fid_7=" & [Record ID#]; // ie the record ID # of the Building you are sitting on. var text ImportChildren = URLRoot() & "db/" & [_DBID_OF_CHILD_TABLE] & "?act=API_RunImport&ID=10"; var text RefreshPage = URLRoot() & "db/" & Dbid() & "?a=doredirect&z=" & Rurl(); $SetTargetBuildingAndNumberToCreate & "&rdr=" & URLEncode($ImportChildren) & URLEncode("&rdr=" & URLEncode($RefreshPage)) Another way to do this with a simpler setup would be to have the same helper table for Suite Helper and trigger a Pipeline with a checkbox on the Buildings table to Search that Table and then get rid of the loop that the Pipeline setup will offer and instead use the relatively new "Import to Quickbase Step" Either way a Helper table with records from 1 to 1,000 will give you some help. Feel free to post back with questions or if need be I can hop on a fast call with you next week. Re: How to group a report by individual values in a Multi-select Text field? re: "So for me to properly report I will need to do the same with my projects table and create that junction child table of project products?" Yes, somehow you will need to create that Child Table for Project Products. You could use a Pipeline for example to create the children. You would have to figure out what the trigger is for the pipeline to run, and it might have to trigger and delete the Project Products child record tables for that project and recreate them when it changes made elsewhere in the app. Re: How to group a report by individual values in a Multi-select Text field? The fundamental problem that you're up against is that on any report type or chart a particular Quick Base record can only appear once. So for example, imagine a pie chart, you can only have the project of fear appear once on that slice of pie. The same project cannot appear in multiple slices of the pie. So one approaches to change from a down and dirty multi select field to a relationship where one project has many Products. If you'd like, you can still roll up a summary field of the different products that are involved on a project so you can have them on a Table report up on the project level. But then you would run your reports down on the child table. The child table would likely be called something Project Products. He would set up a table of Products, and you already have your Projects table and then you would set up a new Many to Many join Table where one Project has many Project Products and one Product has many Project Products. Typically, you would then put an embedded report of the Products on your Projects Table. If you are unwilling to go through that change to the structure of your app, then your own alternative is to put a dynamic filter on the report for your multi select field and select them one by one to count the number of records on the report or see the number of records on some kind of summary report or pie chart. If you're interested in transitioning your data over to a "proper" child Table with the Project Products, and you need help, post back here and I can help you with any questions you have in building that child Table or populating it with your initial data from that multi select field. Re: Trying to use a URL field in Rich Text formula field to display and image Can I see what that actual URL looks like? You can the root part of the path if you like. Re: Trying to use a URL field in Rich Text formula field to display and image Maybe try this "<a href=" & "<img src=" & [Photo Exterior Front from website] & "</a>" ... but I also offer some syntax below which I have used which should give you a clickable image, so that the initial display image can be set smaller, perhaps for a report and then you click the image to see the full size. In my example, the fid for the image is 12 and the field name for the file attachment field is [Team Member Picture] the 100 sets the height of the image, so you can try different heights. var text image= "<img src=" & URLRoot() & "up/" & Dbid() & "/a/r" & [Record ID#] & "/e12/v0' height='100' >"; var text URL= URLRoot() & "up/" & Dbid() & "/a/r" & [Record ID#] & "/e12/v0' target=_blank"; If([Team Member Picture]<>"", "<a href=" & $URL & ">" & $Image & "</a>") Re: JSON Array Iteration @Georg This sounds really powerful, I am hoping that Quickbase runs Qrew demo of this. Re: Workaround for 20 Option Max in Multi-Select Text field? I suppose one pretty elegant solution would be to have a pipeline ensure that the parent record always has the 50 state children records and have your users use Grid Edit on the embedded report to select the states they want. So they would not be adding the states one by one, the states would already be loaded and they were just checkbox the ones they want. You could also consider having a URL formula button, which would either check them all or uncheck them all to deal with situations where the user wants either all 50 states or almost all the 50 states in which case they could click a button to check them all and then deselect the ones they don't want. There are elegant ways to do this with a URL formula button, so that the response on the screen would be instantaneous, the user would click the button and the page would refresh with all of the check boxes checked or all of them unchecked. This Mass checking or unchecking can also be done with a Pipeline where maybe the set up is a little more intuitive but the response on the screen is not quite instantaneous. The user would probably have to refresh once or twice to see the effects of the pipeline running. Re: Sync table and pipelines Since it is just a few records per day, then you can just directly do the search and then the For Each loop will add the required records. I was just offering a more generalized response for the situation when there are 1,000s of records to be added. There is a step in a Pipeline called a Bulk Upsert. So what happens is you have a step to create essentially an empty box with identified fields in it. That is the Bulk Upsert container. Then the For Each loop will add Rows to the container (there is a pipeline step type for that), and then outside the loop you "Commit" the upsert. (also a Pipeline step type) The effect of that is that it has the least impact on the performance of your app. There is just one query to identify the records and then in a separate process run by the pipeline and not impacting your app at all, it fills up the box with the records that are going to need to be added. Then the Bulk Upsert box is imported all at once, which is very efficient for Quickbase to do. The alternative if you just do it by brute force would be to do a search that returns say 1000 records and then the For Each loop would add those records one by one. That places a lot of load on the app as you are basically asking the app to do 1000 individual activities on your app. So it would slow down the app a little bit for your regular users until those all completed and it also introduces the possibility that the app gets so busy that some of the records failed to get added, and the pipeline has a hard error for some of the records. In your case, the more complicated method is not necessary, so I just offered that by way of education for maybe a future situation where there are thousands of records to be added or merged into a table. Mark