What do people really think about BAQ's?

Kinetic ERP
20

sure its easier to write the direct sql

you said it not me :wink:

But as soon as I start joining other tables, the visualization that baq’s give me to be able to see what’s going on make BAQ’s way more powerful for me to be able to see what’s going on. If I had to parse a complicated SQL query and understand what it’s doing it would take me a LONG time to be able to just see it as simply as I can see it in a BAQ.

ok not sure what you are using for looking at SQL, there are plenty of tools that allow you to see diagrammatically what an SQL query does and trust me it looks a lot better. also many IT guys I know that work with BAQ’s look at the “estimated SQL” to figure out what is wrong with the BAQ as it’s quicker that way.

Programming languages are the same. You get used to one, and it’s a pain to change to something else.
Not sure about that, I know about 20+ programming languages and enjoyed developing in all of them. Sure its a challenge but what is life without challenge. My point is that BAQ’s are not a language. They have no purpose or usefulness outside of Epicor. However anybody on this forum who has gained any knowledge of SQL from working with BAQ’s will almost undoubtedly benefit from that knowledge in their career. Just think of how much value you would be to your next company if you had spent as much time perfecting your SQL skills as you did your BAQ skills. SQL skill is just so much more valuable than BAQ in the job markets.

21

I can’t think of a single professional coder that hasn’t :poop:all over every no-code / low code product that has ever come out. I think you are so far above the target audience that its never going to seem valuable to you. My intuition is the outrage would be massive if they got rid of BAQ’s.

3 Likes
22

Yeah it is. It’s just a way to communicate to the computer what you want to do. All of the options are accounted for in both, one just wraps it into a UI to click through the options instead of typing them.

2 Likes
23

BAQs respect Field Security. Epicor implemented field security at the application level making it easier to manage by security groups. No need for Altering the database schema.
SQL already has a security model which Epicor ignores in favour of a service account which has access to everything. their software simply provides a filter to a fully open connection to everything. not my idea of security of data

BAQs respect Company and Site security. An SQL author would have to remember to correctly return different results based on the user running the query. You are probably right but I find the company and site security a bit of a pain if I am honest

BAQs respect Territory Security. An SQL script would have to limit records based on the territory that the user has access to.You are probably right but again this is a bit of a pain and just as easy to build into SQL

BAQs hide User Defined field details from the author. An SQL programmer has to know to use a view or manually make the linkage. I agree with this but I find that knowing how something works is better than not. hidden details are not in my best interest

BAQs hide the details of the PatchFld table. While Epicor doesn’t make any schema changes at the patch level, sometimes they need to add a field. The PatchFld table is a hack to add a field without changing the schema and a BAQ will automagically handle this for you. That’s a fair point but lets no forget it was Epicor that invented this and is the reason why you have to do it in the first place

24

This reply is so funny I am going to mark it as the solution and leave it there

25

Looks like you should go join Kevin and work on a new ERP system. You got it all figured out man.

1 Like
26

I haven’t seen a very well-implemented record level security model in SQL that’s easy to maintain.

I LOVE to know how things work, that’s the best part of this job. At some point, am I spending too much time reinventing something that has been solved or adding value to services that moves the company forward? :person_shrugging:

It’s no different than a car, plane, or encryption, or whatever. It’s good to know something about a topic for sure, but if I spend all my time trying to become an expert mechanic, aerospace engineer, cryptographer, or an Epicor Database Architect analyst, I’ll never get anything done. We all get a chance to pick our battles.

Channel 9 Australia GIF by The Block

27

I’m not so sure about that. I imagine, unless he is very stubborn, will follow the progression like
the rest of us.

You’ll go from not liking it at all, to realizing the power behind it, to bending it to your will to do
things no one even imagined.

I was going to write out a long reply, but it seems @josecgomez , @Banderson , @Mark_Wonsil ,
among others took most of the words out of my mouth.

I will try to add a few bits.

Sure, it’s an abstraction, but one benefit, is it is one you don’t have to write. It’s built and is very
powerful.

Amen

You don’t like it now because you came from an SQL background, as did many of us, and it’s already
been said, but yes for many things it’s not as efficient. However once you get to working with the
tools, you’ll start to build up libraries of powerful things you can lean on. Especially with UBAQs.

You get many tools in one toolset, it’s a query writer, a schema explorer, a programming tool as
well. Before functions, and now in combination, it is a wonderful tool to get data in and out in a
way where I drag and drop a few things, add a few bobs of code for transformation, and write
whole applications in a few days, where before it would take weeks.

So much power here, so much so that I have to be careful.
It’s really nice to be able to use the designer to make an “interface” of sorts to get the data in and out,
and do complicated stuff in backend. I’d take LINQ over SQL almost every time.

It’s telling in the sense that we know what your background is. Try telling that to someone who has never seen SQL. Sure, they’ll get the basics, but I’ve seen moderate level users write quite complex BAQs that I’d have trouble with in SQL.

In Epicor, data validation and business logic is primarily wrapped up in the business objects, so unless you have intimate and vast knowledge of how it all works, you’d be playing with fire. Some of us still do, but we know the risks, and usually do so with significant research. I like the abstraction.

Alas, this is true; It’s a pain point I struggle with.

Yeah, it’s improving, and one day may be awesome, but yeah, for serious work it’s not ready.
I am not however sitting on my ass, I’m learning it anyway.

Anyway, you may come around, or you may not. These are all just our opinions.

I do however think that your position will evolve over time if you stay in this ecosystem.

Who knows, you may even contribute to making it work better.

I don’t shy away from adversarial positions, and I don’t intend to encourage others to do so. As long as we can all learn something at the end of the day, and keep it civil, your opinion is welcome, at least to me.

9 Likes
28

I see this horse has been beaten to death, but I’ve never had anything to add on the forum until now.

I really feel like the target demographic for BAQs. I grew up with computers but sadly never went to school for programming, though I like to think I could have done so. Having recently changed course from graphic design to business analyst, BAQs and other tools provided in Epicor have been my gateway to doing this sort of work.

I’m really thankful for my mentor and this forum, I’m always learning both about the Epicor tools and SQL / C#, (admittedly slowly). I guess what I’m saying is that without the consideration to make the graphical interface that is BAQ, I wouldn’t have had this opportunity. I think it could provide a stepping stone towards writing SQL directly, but it also stands on its own.

You may not agree that its as powerful or as easy for SQL users as SQL itself, but for users like me, its a godsend. Maybe that can be enough?

8 Likes
29

Late to the party as usual! As someone with SQL and DBA experience who leaves the keyboard as a last resort, allow me to sing you the song of my people:

  • BAQ is an ergonomic nightmare.
  • I’ll add my concern that the security and obfuscation applied by the BAQ client only effectively applies to approved, technically unskilled or incurious, non-malicious users. It’s irrelevant to anyone who might look for a path around the BAQ client.
  • BAQ’s dependency on sp_executesql (PSA to anyone who didn’t know that…) sets off my DBA heebie jeebies and makes query optimization beyond the extreme basics a ouija board experience.
  • It’s ambitious beyond its means in trying to support novice users, to the point it sometimes requires SQL expertise to understand how to accomodate its clunkiness.

At least it’s there and mostly works. I’m glad it exists and use it all the time, or at least until a RSI flares up.

30

While I don’t necesarely agree with much of what you said I do agree that executing queries via sp_executesql drives me nuts.

To that end… and Idea! (Have BAQ Designer Generate a Stored Proc or Table Value Function) it already generates one on the fly to feed to sp_executesql … so why not generate a proper one and execute that instead!

https://epicor-manufacturing.ideas.aha.io/ideas/KIN-I-3654

2 Likes
31

I knew it was ideas day.

Vetoed!

I mean voted.

32

I have not read all the nice comment here. :slight_smile:
FYI - if you rather write “sql queries”, you can , you create your SQL queries in you in the database and link it via External Business Activity Query in EPICOR.

33

Absolutely. When I need quick data I’ll more often than not jump straight in with SQL. But I’d be terrified to give most of my users this kind of knowledge or access! Whenever I need to deliver data to users on a repeat basis it’s BAQs all the way. Couple them with dashboards and we have user-friendly tools without the fear of users breaking the system.

Additionally, creating a BAQ and accessing it via REST has been a bit of a game-changer for us, especially when we can control the security through access scopes within Epicor. As far as offering visuals of our data to our users, BAQs are definitely our preferred option.

5 Likes
34

I also still prefer SQL select statements in stored procedures. However, I can work with BAQs. In my opinion BAQs are so much better than what other applications provide to query data.

1 Like
35

Are we able to use SQL Management Studio to reach out to our data in Kinetic Cloud or are BAQs always a requirement to select queries? I am working on DMT and am interested in looking at the data in my FOURTH database and would rather do a quick SQL Select query than write a new BAQ and then go back and edit it when I want to change one param.

36

No.

There is a replicated database option you have to pay for that should give you similar functionality.

1 Like
37

Did you know that you can execute BAQs through a REST endpoint (BAQSvc) and pass in parameters on the URL? It’s faster than opening up SSMS alone.

4 Likes
38

I often find myself writing quite broad BAQs these days that gather a lot more data than the user requires. Our REST endpoint passes in the fields it needs through the $select parameter, filters to specific data with $filter, limits the number of results with $top etc. There’s single BAQs I access with different applications using different filter params to give completely different sets of data. BAQs via REST have changed my approach to the style of apps I’m delivering to our users due to their versatility and reusability.

BAQs might take a little more time to set up than the “quick SQL” approach, but if done with a bit of foresight they’ll end up saving you a ton of headaches down the track.

3 Likes
39

When I need to pull data in a UI Screen, I just use a BAQ instead of Adapter, BO… because its much easier, much faster than GetRows or GetByID and I can get specific data… name your BAQ CODE-GetCustomers pass in some params and viola.

Even when I want to show stuff yellow in a gid… I just have a Calculated_IsException and if I ever want to change the logic, I modify the BAQ and Row Rules will behave accordingly.

As @josecgomez said – most powerful tool… and I’ve done some wild things with BAQs.

3 Likes