KurtJohnson
Qrew Member
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: Upcoming Changes to JavaScript in Quickbase
@Evan Martinez, I think my #1 concern with this is the aggressive timeline for Rich Text. We have at least one very large "multi-use" Rich Text button field where various JS solutions/features are buried inside a large nested IF/Case statement. Each "THEN" is a different JS feature requiring its own independent migration effort. A few questions: 1. We won't lose functionality in April, but will we lose the ability to incrementally remove individual JS features from this field described ? Example: remove 1 JS feature and Save (net reduction in total JS within the field) 2. Assuming a field only has 1 JS solution in it, can we edit it later to remove JS and still save on the same Field ID ? 3. Will we be able to change other properties on the field such as field name/label after a cutoff date ? Or is the entire field essentially shut down until we make a new one to replace it ? 33Views0likes0CommentsRE: Introducing Pipelines - Webinar Q&A
Let me ask it a different way for Rhett... (1) Today an Automation is triggered by a QB created/stored/somewhat-hidden Webhook that packages up every field in the record (whether needed or not for the Actions) and ships it off to the Automation engine for processing. Are Pipelines essentially using the same methodology? or is it a tighter integration? (2) And Mark, I'm with you... I believe Rhett is really wanting to know if a Dialogue box could kick off a Pipeline and then perform an Action after the Pipeline is finished running.... providing a path away from Javascript / IOL solutions. High level use case: a. User clicks on Pipeline trigger button (new field type?) b. QB App presents dialogue box with progress bar / spinning wheel / etc c. App triggers appropriate endpoint Pipeline configured in the QB PIpeline trigger field d. Pipeline Success = dialogue box shows "Success" and then performs an action (refresh page / redirect / etc)... possibly configurable returned data payload so it can be utilized in the Action e. Alternately, Pipeline Failure... display the error to the end user ------------------------------ Kurt Johnson ------------------------------12Views0likes0CommentsRe: Formula URL Line break /n not functional with Text - Multi-Line field
The following syntax works fine within a Text Multi-Line field... noticed you had a "/n" instead of the appropriate "\n"... wrap that with URLEncode() URLRoot() & "db/" & [_DBID_XXX] & "?a=API_GenAddRecordForm" & "&_fid_7=" & "Test description line 1" & URLEncode("\n") & "Test description line 2"28Views0likes0CommentsRe: Quick Base Memory Calculations
To piggy-back/expand upon what Harrison is saying, Cross-app relationships is a fantastic and useful feature. The risk is that doing so pulls both apps into the same CPU/Memory space within the QB cloud. With large user volumes and/or large data sets... this can pose a problem. For example, performing a large data import to App-A will impact the performance of App-B during that import as they are sharing resources when a cross-app relationship exists between the two. Essentially any action on either app will affect that each other due to queuing within the single thread of allotted. If I remember correctly... the following features/actions within a QB app will pull both apps into the same memory space: 1. Cross-App relationship 2. Report Link with an external App 3. Table-to-Table Imports with an external App 4. ...I think I'm missing one or two others? NOTE: Connected Tables does not pull the apps into the same CPU/Memory space as it acts more like a traditional ETL (Extract-Translate-Load) process to transfer data between the apps based on a refresh rate that you choose.7Views0likes0CommentsRe: Quick Base Memory Calculations
I was reviewing the Feb release notes under the early access which pointed me to this thread. I definitely feel it's on the right path. I just wanted to provide some of the next steps to truly unlock the infinite usage fingers that sprout from a field after it is first created. Don't get me wrong, the flexibility of Quick Base is phenomenal... but as you've pointed out... with that ability, comes great power to cause unexpected harm to end users. From where I sit... the unexpected can be controlled by providing additional tools to visualize your field/relationship/formula impacts to the application before fully implementing them.38Views0likes0CommentsRe: Quick Base Memory Calculations
Mark, to put it in perspective... I've been managing an Enterprise Project Management app for several years now that is currently ~2.9GB in size with ~1300 registered users. This app easily swells over the allotted RAM limit. Upon exceeding the limit, an application will reboot without notice. We don't have any monitoring abilities to understand what our current RAM footprint is at a given time... so hitting a limit like this in business hours can easily cause a 30+ minute outage for the app to reboot and for queuing to come back under control with reasonable responsiveness. We've been partnering with QB staff and our QSP for the past 9 months (including Harrison) to combat the issue with mixed results. Though we've optimized reporting/dashboards/limited-personal reports for quicker response times... our RAM consumption issue still persists. I do believe that if we could create an hour of "quiet" time for the app to go-to-sleep / unload itself at night, the issues would not occur anymore. The app never puts itself to bed currently. This a very difficult item to control with the vast user base, nightly processes for our company, and nightly processes configured within Automations themselves. We need 30-minutes of zero utilization for the app to unload itself. I'm confident we'll get this figured out, but our users are definitely frustrated.33Views0likes0CommentsRe: Quick Base Memory Calculations
This all makes sense, though it becomes difficult to 'trace' where heavy fields are causing utilization issues. It would be awesome to have an admin tool that could loop through a source field, all of it's uses, and come back with an impact statement for that field... such as total RAM consumed from this field and all of it's derivatives... possibly listing the RAM consumed for each usage on the field usage tab. It's very difficult for developers to put a finger on which fields are causing the most consumption in a given app without extensive research and computation outside of the application. This type of solution would empower developers to design within the limits of an allotted app and explore alternative solutions that are possibly not as RAM intensive but yield the same results for end users.54Views0likes0Comments