ContributionsMost RecentMost LikesSolutionsPipeline Error Emails - There has been an error in your pipeline. Earlier this year, the people incharge of the development of Pipelines stated on a zoom call, that the Pipeline Error messages would be improved & become more useful. Here were are almost a year later, and I still receive emails with a subject line of "Error on Pipeline 5449755848XXXXXXX" with the generic body of "There has been an error in your pipeline." Unless I click on each email, I don't know if the message is anything we need to worry about. If you are like us, we have a LOT of pipelines. Some that have periodic errors, that we can't control or fix. So basically these emails have gone from "something is broken; look into a fix", to the boy who cries wolf (and are ignored, until someone notices an update hasn't run for over a day!) We have even gone through the trouble of creating our own QB logging table for our pipelines, where we write a log file at the start time of the pipeline, and update that record at the end of the pipeline (so if the record isn't marked completed within 30 minutes, it becomes an "error". ) This allows us to have direct links to the pipeline activity log, record the file that was used to update a record, show how many records were added/updated/processed, and more. Hoping that someone from the Pipelines team sees this, or someone who is better in the know... who can share when this "improvement" to error emails will be realized. Even if they just replace "Error on Pipeline 5449755848XXXXXXX" with the name of the actual pipeline would go a LONG way for most users! ------------------------------ Joe Drosen ------------------------------ Re: Pipelines - Delete unmatched records We often use Pipelines to set "a flag". This could be a check box, or a number, where you take all of the records and give them this flag. This is similar to the above "delete" checkbox. You would then import the data from the other table & make sure that all matched erase that flag... so you can then delete ONLY non-matched records. As far as looping through records, it will take a long time (depending of the size of your table.) We have found that it is somewhat quicker if you use the bulk Record Upsert (Basically as fast as a CSV import is). ------------------------------ Joe Drosen ------------------------------ Pipelines Missing "Switch to User Option" Due to CSR Access Turned On We recently had an issue where we lost the ability to switch between users in Pipelines. This made using Pipelines very difficult, as my boss and I both build and maintain pipelines (but couldn't see each other's work). Our Quickbase Technical Enablement Consultant was unsure why this option disappeared. He said that tech support has a feature that utilizes CSR Access, so they can access our systems without needing to be added as users to our pipelines. It ended up, that by having this option turned on, QB Customer Service Reps can access our pipelines, but also removed our ability to switch between users. This was a surprise to both of us, as this isn't documented anywhere. I am posting this, with hopes that they will add a note under the "Care Access" menu, so that clients are aware of the functionality that will disappear. I have since turned this option off and logged out. Upon logging back in, I can now switch between users in Pipelines once again! ------------------------------ Joe Drosen ------------------------------ Pointer for Uploading Files into Quickbase via API Short Version: When uploading a file attachment via the Quickbase API: the Base64 content should be on a continuous line and not contain any Carriage Returns or Line Feeds / aka CRLF (ASCII Character 13) and LF (ASCII Character 10). You may need to filter out these characters from your Base64 attachment to generate this result. Long Version: Just wanted to post this here, as I spent an entire day trying to upload an image into Quickbase via the API. The response showed that the transfer was completed, but when I went to view the resulting URL, all I saw was a white square on a black background. I opened a support ticket, where the QB tech verified that our XML request was correct and stated that he did some tests without issue, noting "My image uploaded when the string was all on the same line." The solution, my Base64 encoded file needs to be on a SINGLE LINE! It would have been helpful in the API Docs, that it is more clearly stated that Base64 text is supposed to be on the SAME LINE. I tried everything BUT removing the CRLF and LF characters from the Base64 content! Now that I did it, it works! It appears that I was misreading the file management page (OVER AND OVER AND OVER). Here it states "You should not use MIME style encoding with newline characters at a maximum line length of 76." I read this as, you should not use MIME style encoding, but it should have newline characters to cause the line length to have a maximum of 76 characters. This was further supported in the Base64 Encoded File Attachment Example, where it seems to clearly show the data in lines of 76 characters. Looking at the example, I thought this meant that it WAS SUPPOSED to fit the standard 76 characters column width (as the sample request seemed to be formatted in a standard Base64 / 76 character max column.) It wasn't until today, that I counted the characters in the example & found out that the text was broken up into 75 characters. I am submitting this as edits to the above pages, as well as posting this on community.quickbase.com in the case that this info isn't updated in a timely fashion. Perhaps this could help save someone else this confusion. I am asking that they clearly state that the "Base64 should be on ONE continuous LINE with NO CRLF or LF Characters to break the text". Also, editing the file attachment example to make it represent the data on a continuousline (ie: formatting the example in FULL PAGE WIDTH). ------------------------------ Joe Drosen ------------------------------