EricWhitley
Qrew Trainee
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: Quick Base Release Notes for February 2019
I love where this is going. You're hitting all of the areas that we've had on our wish list for a while now. Type-ahead search, distinct counts, reporting formulas, string replacement - everything. Super excited to see the new visual builder and really appreciate the focus on field usage reporting. Awesome stuff. Keep up the great work!1View0likes0CommentsRe: Any interest in an open source set of SSIS components for MSSQL?
QuNect is definitely to be more fully featured because they appear to be creating a whole ODBC interface to the QuickBase API. For me, I need a simple way to let SSIS query data out and pump data back in. I've not used QuNect, but if it's doing ODBC-compatible operations, it should be fine doing that and more. Honestly, the $2k they're charging is extremely reasonable. That said - I can't (for funding reasons), spend $ on software, so I'm quickly writing a simple way to do some very simple interactions with QB. Nothing nearly as fancy or slick as QuNect, but it fits my basic needs and I'm happy to share it in case it might be useful to others.27Views0likes0CommentsAny interest in an open source set of SSIS components for MSSQL?
Hello - Wondering if there are other users of Microsoft SQL Server who might be interested in a simple set of SSIS components (connection manager, data source, and data destination)? I realize there's a commercial ODBC driver out there (which looks great), but I found myself in an odd situation where, for specific reasons, buying software is off the table, but investing time is OK. I've already got some basic stuff working and my intent is to polish it up enough to be useful without needing to know the API: Connection manager for attaching Data source for querying Data destination for writing back (No generalized ODBC like integration where you can do mass deletes) For the data source I'm also going to add something I've found useful on other projects, which is emitting "maybe kinda close enough DDL" for generating your target tables (it just abuses SMO). I've already got this working and it applies some basic rules (sanitizing column names, prefacing the individual address fields with the parent name prefix, etc.) as well as does some very rudimentary guesses on data types. It's mean to be an assist, not an operation you completely trust. I already wrote a generalized "auto sync" process that says "get everything from a database" (simple C# app - creates and runs DDL, merges data over, etc.), but I'm in the process of taking subsets of that and putting things into simple SSIS components. Basic SSIS process - set up the connection manager with your API key and select the database, then in the data source, choose your table. That's it. Done. It's meant to be easy. The only "API-ish" bit I'm exposing (mainly because I'm lazy) is the query. For right now I'm planning on that just being a string you enter. (EX: https://help.quickbase.com/api-guide/index.html#samplequeries.html) I don't want to have to get too far into the weeds right now in building a custom UI for that. I'm currently testing on SQL 2016. If anyone else is interested in testing later, please let me know. I'm happy to ship out a sample DLL. Right now I've got the data source implemented as I try to figure out how MS wants the destination written. Code will eventually get to GitHub once I finish wrapping some basic UI elements around things. Thank you, EricRe: End User Survey
As long as this we can opt our, sure. I don't want that popping up for our C-level customers. At all. Ever. I also agree to the posts above that suggest the feedback should be available to the app admins. Honestly, though - I don't see this as a successful approach to eliciting valuable user feedback that will help drive product improvements. What you're rating is less QB and more the ability of the app admins / developers to build things - which is delicate because there are some areas in which QB is severely limited and it hurts the overall user experience. If you read the discussion forum you see hints of the same themes over and over. "How do I?" "Can we?" For every one of those there's either an implied UX challenge ("how do we make that more obvious?" - ex: setting a field to use a pick list, report link fields, modifying reference fields in relationships, etc.) or a possible product enhancement ("yeah - maybe we need something like that" - ex: regex support in formulas, reports as members of the toolbar [I'd so love that...], distinct results in reports, formula fields in section/tab titles, etc.). All of that impacts our ability to deliver a quality UX - but users won't know that. They're not rating QB. They're rating the app admins / developers. Maybe you should consider surveying the app admins / developers? We have a pretty good handle on things we hear from users and think would be valuable additions to the product. Yes - I know the user voice submission and voting process is there. To me that just seems like a parking lot and not an effective way to manage the feedback process. You guys are doing great work improving with these incremental monthly updates. Let us help you with that. We know our pain points and many times they result in user challenges. Sometimes ones we can't fix right now.1View0likes0CommentsRe: How to relate many records to many other records in the same table?
Huge thank you for this response. I was trying to do the same thing and also struggling. I had to re-read this a few times to pick up on what you were doing, but I think I also got there in the end. What tripped me up was not realizing that an individual field in a form could be linked to a completely separate report as its data source. Finally realized "oh, he means create a report in the source list!" and then put two and two together. Thank you - learned a lot from your walk-through.2Views0likes0Comments