Designing An App

[Cringer]

I am thinking of creating a modern app for viewing a DB schema, sample data within DB tables, maybe user info, and other things if I get a chance.
I want it to be reasonably simple to create and look good. It will run on Windows (sorry Tom!).
So in terms of design, the idea is that the user will be able to select a database to connect to using the standard screens for that. Once connected you will see all tables and fields and indexes for that database.
The thing is, I've little to no experience of other technologies other than ABL GUI so I'm looking for advice.
Getting the data is easy. It will all be done in pcode that's run after creating an alias to the DB in question. It's more about how to design th GUI side. I'm thinking of having a look at the Telerik GUI controls. How would I go about building those? Is there a getting started guide? How do I work with the data from my pcode?
Sorry for all the questions. I'm trying to take the opportunity to expand my knowledge. I'm not too bothered about it being purely OO or anything - just want it to work. But I'd like it to be good to look at, and not reliant on ocx's etc so it's more future proof and transferrable.
Any thoughts and inputs gratefully received! Sorry for the ramble!

 

[Rob Fitzpatrick]

I understand that, even if this type of thing may have been built before, you want to do it regardless as a learning exercise. But it may be helpful for you to look at other tools that have some similar functionality, for feature ideas if not for UI design.

It sounds like there's a fair amount of feature intersection between the app you've described and Patrick Tingen's DataDigger. Another one I use regularly, almost daily, is White Star's DB Report tool; not sure if it's still available though. Looking at those might give you some good ideas. I can't help you with UI programming though.

It's a shame that PSC doesn't invest in DB tooling support, outside of OEE/OEM. The in-box Data Admin/Data Dictionary are really showing their age. And not having even a basic data browser is just unacceptable.

 

[Cringer]

Thanks Rob. I've had access to a similar application in the past, but due to the fact it was written on company time by an esteemed colleague it remains the IP of the company in question and they have no interest in making it open source.
I'll certainly have a look at DataDigger for inspiration.

 

[tamhas]

ProTop as well for inspiration.

 

[Phillip]

Sorry in advance if I don't fully understand what you're asking. It depends on how clean you are looking for the interfacing of data and what platform you are looking for outside of Windows, if any. I have used the Appery.io mobile builder which is very easy to use if you can learn a little Javascript and CSS/HTML as it will create you a deployable mobile app on these three languages alone. It will support a dynamic interface if you want to tie in Bootstrap so you can scale it from mobile to desktop use and deploy as such. For the data, you could just dump from the _file and _field tables to a text file and import to the app for dropdowns, tables, etc. It's not clean but it definitely works.

Hope something in here helps. You guys are way ahead of me in Progress knowledge so please excuse any frowned upon methods of data transfer suggested (text dumps and imports rather than connectors)

 

[GregTomkins]

+1 for DataDigger. But if you want anyone to actually use it, do it in a browser. If you want to learn something new, do it in Angular or React. Or jQuery if you want to do it relatively painlessly

 

[tamhas]

James, isn't this already there in PDSOE?

 

[Cringer]

Not in any way I've ever found it to be of use Thomas.

 

[tamhas]

Well, the schema is there, with detail, and sample data ... and, of course, the SQL editor allows one to do some quick queries ... so it has a lot of the read-only functionality.

 

[Cringer]

Yeah I know there is some stuff there but unfortunately I've not managed to access it in a way that's at all useful to me, there's functionality I want that isn't there and I believe it has dependencies on SQL too that I don't really want.

 

[tamhas]

Well, yes, it is SQL based, but for the purpose, I don't know that is a bad thing given the purpose.

 

[TomBascom]

SQL is the very definition of bad

 

[tamhas]

What does it really matter, if it presents the information you need. Using ABL in the context of a Java PDSOE would present many issues while SQL fits right in with no ambiguity. To be sure, I don't like doing work in SQL much ... although there is something to be said for a run time query optimizer for reporting, but in the context of PDSOE I see no reason to be knee jerk negative about using it. In fact, if James wants a tool that is not tied to the underlying Progress install, he will have to use it too ... like it or not.

 

[Rob Fitzpatrick]

What does it really matter, if it presents the information you need.

It matters from a configuration perspective. If you are developing an application that supports only ABL remote clients, then you only need to provision a 4GL broker. Having to use a SQL connection in PDSOE means provisioning an additional broker and all that that entails for each DB: broker port, server minport/maxport, -Mpb, -Ma, adjusting other params accordingly (e.g. -n, -Mn), pushing firewall rules, etc.

Not difficult, but a bit of a pain.

But if you can write an ABL client to present the info you need then there is no additional DB configuration required.

 

[tamhas]

But the ABL client is dependent on the Progress installation and thus subject to version differences and the like. But, then, I am used to all of my customer's sites being configured with SQL anyway since it was used for the reporting tool. And, of course, if one is going to use PDSOE, one has to have the SQL connection anyway.

 

[TomBascom]

I'm sold -- sounds like a pretty good reason to avoid PDSOE.

 

[tamhas]

Back to Emacs?

 

[TomBascom]

Microemacs actually and while I have occasionally fiddled with this new-fangled IDE foolishness I've never really left. It's hard to improve on perfection...

 

[Rob Fitzpatrick]

if one is going to use PDSOE, one has to have the SQL connection anyway.

Is it necessarily the case that a SQL connection is required? Or just if one wants to use the DB Explorer view and have statement completion on DB objects?

 

[Cringer]

I don't have SQL connections to my databases defined in PDSOE. It will happily suggest table/field names for auto completion but I can't use the schema explorer.