Thread: Recomended front ends?

Recomended front ends?

From
stan
Date:
I am in the process of defining an application for a very small company
that uses Postgresql for the backend DB. This DB will eventually run on a
hosted machine. As you imagine all of the employees have Windows machines
for their normal work asks. Frankly I am not very strong on Windows. so I
am wondering what the consensus is for creating forms and reports? 

My first though is Libre Office as that is cross platform, and i can test
on my development Linux machine. However, i am getting a bit of push-back
from the user as he is having issues with installing Libre Office on his
computer. he says it does not play well with MS Office. Also we seem to be
having some bugs with Libre Office Base in early development.

What is the community wisdom here?

-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
                        -- Benjamin Franklin



Re: Recomended front ends?

From
Igor Korot
Date:
Hi,

On Wed, Aug 7, 2019 at 1:57 PM stan <stanb@panix.com> wrote:
>
> I am in the process of defining an application for a very small company
> that uses Postgresql for the backend DB. This DB will eventually run on a
> hosted machine. As you imagine all of the employees have Windows machines
> for their normal work asks. Frankly I am not very strong on Windows. so I
> am wondering what the consensus is for creating forms and reports?
>
> My first though is Libre Office as that is cross platform, and i can test
> on my development Linux machine. However, i am getting a bit of push-back
> from the user as he is having issues with installing Libre Office on his
> computer. he says it does not play well with MS Office. Also we seem to be
> having some bugs with Libre Office Base in early development.
>
> What is the community wisdom here?

What language/tools you are most comfortable with?

Thank you.

>
> --
> "They that would give up essential liberty for temporary safety deserve
> neither liberty nor safety."
>                                                 -- Benjamin Franklin
>
>



Re: Recomended front ends?

From
Adrian Klaver
Date:
On 8/7/19 11:57 AM, stan wrote:
> I am in the process of defining an application for a very small company
> that uses Postgresql for the backend DB. This DB will eventually run on a
> hosted machine. As you imagine all of the employees have Windows machines
> for their normal work asks. Frankly I am not very strong on Windows. so I
> am wondering what the consensus is for creating forms and reports?
> 
> My first though is Libre Office as that is cross platform, and i can test
> on my development Linux machine. However, i am getting a bit of push-back
> from the user as he is having issues with installing Libre Office on his
> computer. he says it does not play well with MS Office. Also we seem to be
> having some bugs with Libre Office Base in early development.

Yeah, I gave up on Base awhile back due to its flaky performance.

> 
> What is the community wisdom here?
> 

What I have done is gone the Web route. In my case using Django as the 
framework/backend and the users browsers as the clients. That greatly 
simplifies keeping up with changes on the client end. There is still a 
need to deal with cross browser issues, but that is less of a chore. As 
Igor's post said it comes down to what you are comfortable with.



-- 
Adrian Klaver
adrian.klaver@aklaver.com



Re: Recomended front ends?

From
Rob Sargent
Date:
On 8/7/19 1:38 PM, Adrian Klaver wrote:
> On 8/7/19 11:57 AM, stan wrote:
>> I am in the process of defining an application for a very small company
>> that uses Postgresql for the backend DB. This DB will eventually run 
>> on a
>> hosted machine. As you imagine all of the employees have Windows 
>> machines
>> for their normal work asks. Frankly I am not very strong on Windows. 
>> so I
>> am wondering what the consensus is for creating forms and reports?
>>
>> My first though is Libre Office as that is cross platform, and i can 
>> test
>> on my development Linux machine. However, i am getting a bit of 
>> push-back
>> from the user as he is having issues with installing Libre Office on his
>> computer. he says it does not play well with MS Office. Also we seem 
>> to be
>> having some bugs with Libre Office Base in early development.
>
> Yeah, I gave up on Base awhile back due to its flaky performance.
>
>>
>> What is the community wisdom here?
>>
>
> What I have done is gone the Web route. In my case using Django as the 
> framework/backend and the users browsers as the clients. That greatly 
> simplifies keeping up with changes on the client end. There is still a 
> need to deal with cross browser issues, but that is less of a chore. 
> As Igor's post said it comes down to what you are comfortable with.
>
>
>
And if you choose to go down the web route, and you're not intimately 
familiar with at least one of the strands, get help immediately. There 
is much, much magic involved.



Re: Recomended front ends?

From
Igor Korot
Date:
Hi,

On Wed, Aug 7, 2019 at 1:57 PM stan <stanb@panix.com> wrote:
>
> I am in the process of defining an application for a very small company
> that uses Postgresql for the backend DB. This DB will eventually run on a
> hosted machine. As you imagine all of the employees have Windows machines
> for their normal work asks. Frankly I am not very strong on Windows. so I
> am wondering what the consensus is for creating forms and reports?
>
> My first though is Libre Office as that is cross platform, and i can test
> on my development Linux machine. However, i am getting a bit of push-back
> from the user as he is having issues with installing Libre Office on his
> computer. he says it does not play well with MS Office. Also we seem to be
> having some bugs with Libre Office Base in early development.
>
> What is the community wisdom here?

On top of what already been said - make sure that the product you are
about to start
working on will have its requirements clear and concise.

What is expected from the software?
Does it needs to go out and access the web?
Is the company split between different areas of the country/state?
Does it needs to support Windows only?
Will there be a need to a handheld device or bar code scanner?
Will printing be involved?

List is preliminary and can go on and on. Its just first that comes to mind.

Get the requirements from the company management, make sure you understand them
check you knowledge of different tools available and their support of
the feature requested
and start working.

Good luck!!

Thank you.

>
> --
> "They that would give up essential liberty for temporary safety deserve
> neither liberty nor safety."
>                                                 -- Benjamin Franklin
>
>



Re: Recomended front ends?

From
Rich Shepard
Date:
On Wed, 7 Aug 2019, Igor Korot wrote:

> On top of what already been said - make sure that the product you are
> about to start working on will have its requirements clear and concise.

This is a critical process that needs to be developed in depth. One
criterion that will guide your choice of UI is whether the database will be
accessed only on the LAN or also remotely. For the former, consider using
Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based
application using Django.

HTH,

Rich



Re: Recomended front ends?

From
Tim Clarke
Date:
All excellent solutions, may I add Lucee to the list. We call it "the
best web development system no-one knows about".


Tim Clarke
IT Director
Direct: +44 (0)1376 504510 | Mobile: +44 (0)7887 563420

On 07/08/2019 21:38, Rich Shepard wrote:
> On Wed, 7 Aug 2019, Igor Korot wrote:
>
>> On top of what already been said - make sure that the product you are
>> about to start working on will have its requirements clear and concise.
>
> This is a critical process that needs to be developed in depth. One
> criterion that will guide your choice of UI is whether the database
> will be
> accessed only on the LAN or also remotely. For the former, consider using
> Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based
> application using Django.
>
> HTH,
>
> Rich
>
>


Telephone: Witham: +44(0)1376 503500 | London: +44 (0)20 3009 0853 | Frankfurt: +49 (0)69 7191 6000 | Hong Kong: +852
58031687 | Toronto: +1 647 503 2848
 
Web: https://www.manifest.co.uk/



Minerva Analytics Ltd - A Solactive Company
9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | United Kingdom

________________________________

Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee
youmust not use or disclose such information, instead please report it to
admin@minerva.info<mailto:admin@minerva.info>
Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd: Registered in England Number 11260966 & The
ManifestVoting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here
https://www.manifest.co.uk/legal/for further information.
 

Re: Recomended front ends?

From
Tony Shelver
Date:

On Wed, 7 Aug 2019 at 20:57, stan <stanb@panix.com> wrote:
I am in the process of defining an application for a very small company
that uses Postgresql for the backend DB. This DB will eventually run on a
hosted machine. As you imagine all of the employees have Windows machines
for their normal work asks. Frankly I am not very strong on Windows. so I
am wondering what the consensus is for creating forms and reports?

My first though is Libre Office as that is cross platform, and i can test
on my development Linux machine. However, i am getting a bit of push-back
from the user as he is having issues with installing Libre Office on his
computer. he says it does not play well with MS Office. Also we seem to be
having some bugs with Libre Office Base in early development.



I went through this some months ago, and put out a similar query to this list.
It very much depends what type of app / data you are trying to address.
If you are considering something like Base:  what your is users' level of  expertise, and your appetite for distributing / maintaining / installing the app and it's infrastructure.

Options
I looked at several options, and ended up using Base as a quick and dirty front end to build a content management system for an eStore. 
I looked at a few other options, including Kexi.  Most I ruled out as they didn't seem to have active support communities.
One interesting looking one I played with a little was Kexi,but you need to build your database through Kexi (https://kde.org/applications/office/org.kde.kexi). 
One of my constraining factors was that I didn't want Kexi to build the database for me, as I have a DB schema graphical design and generation tool I prefer to use (pgmodeler).

Bugs / features / learning curve
I didn't find any bugs in Base that caused me problems, more like missing features, or features that don't work the way I'd expected.
With a good Youtube series for a guide, I got a reasonable application up and running in a weekend. I do have a basic development background dating back to tools such as Oracle Forms, Mantis, and various other products of that ilk. Also have a little experience with MS Access, and Cobol and Java app generation.

End-user 'friendliness'
I would be a little wary of using Base for robust end-user data interaction, unless the users are fairly savvy on how to work with something like Base or Access applications.  Things like deleting, inserting, and updating data on the forms are not all that intuitive at first, especially if you have multi-table forms (I have 4 tables embedded on my product form).

Some limitations
  • You will need to be a bit aware of Base macro programming.  Base does not have anything like VBA to work on.
  • You will be limited on the type of application you can deliver.  Basic data editing, probably suitable.  Something more complex like selectable calendars, WYSIWYG text editors and so on, not so much. For example, I would love to include a markdown text editor for product descriptions (which Jekyll or Python can convert to HTML).  Trivial in Vue.js or Quasar, not so much in Base, where I have to cut and paste the text to and from an editor.
  • Using Base to search / navigate through large datasets is not very easy, and you need to think very carefully how you will design around this.

I am using my application quite regularly to maintain the data, but intend to replace it with a javascript (Vue and / or Quasar) front end at some stage.
One comment on the recommendations to create a web application, if you do not have current skills in Python or javascript and probably stuff like CSS  / HTML the learning curve can be very time consuming.

Security:
Another issue is security.  If the database is accessed within your corporate firewall, then it's not too bad.  If you need to access it from across the internet using standard postgres drivers, then you may want to have a careful think as to how you can lock down access to the database. I allow postgres to communicate only to specific IP address ranges, and I also have the firewall set up to restrict access to port 5432 to a few specific IP ranges.

When it comes to pulling the product data out of the system, that's only through a GraphQL interface to a GraphQL server.  That was pretty easy to generate.  I pull the data out via a Python program, which in combination with Jekyll static site generator generates our 3 websites, The python program creates XML product file feeds to Jekyll, and in other cases generates the basic HTML product page for Jekyll to complete site generation.

Most can ignore from here
For a weekend's work and a day or two of later enhancements, the Base app works pretty well.
To give you an idea of the complexity it consists of:
  1. Site: The domain name, the site base directory, discount and tax percentages
    • Block to add / delete / display product categories applicable to the site
  2. Category: the product category, discount levels, and a set of attributes on where to place the generated data (XML catalog file name and directory, where product page templates are found and so on. category images are uploaded and displayed directly to / from the database on this page, and there is a block listing products within the category.
  3. Brand: Product brand management, including uploading / deleting / deleting brand logo images.
  4. Product: A full set of product attributes including covering all schema.org attributes and those required by Snipcart shopping cart, payment and shipping gateway.
    • Product images uploaded / maintained
    • Product categories block as a product can live in several places
There are a few other sundry pages to display or edit data in specific ways.

Re: Recomended front ends?

From
Stuart McGraw
Date:
On 8/7/19 2:38 PM, Rich Shepard wrote:
> On Wed, 7 Aug 2019, Igor Korot wrote:
> 
>> On top of what already been said - make sure that the product you are
>> about to start working on will have its requirements clear and concise.
> 
> This is a critical process that needs to be developed in depth. One
> criterion that will guide your choice of UI is whether the database will be
> accessed only on the LAN or also remotely. For the former, consider using
> Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based
> application using Django.
> 
> HTH,
> 
> Rich

I would be a little cautious about Django.  Last time I checked,
like many other web frameworks, it treats the database as just another
component, one that provides data persistence for it, and consequently
imposes its own constraints the schemas it will work with.  Specifically
IIRC it insists that tables have a single-column primary keys.  If the
client's existing database is already designed this way then that may
not be a problem but if it has composite PKs then another option may
be better.

Flask is another relatively easy to use framework, can be used with or
without Sqlalchemy but doesn't have the wealth of addons available with
Django and being simpler requires more work to build the end application.
There are of course many other framework options (Bottle, Web2Py, etc)

Although it's been a decade plus since I worked with Microsoft products
I had fairly good luck back then using Microsoft Access / VBA connected
to a Postgresql backend via ODBC.  Even back then MS's frontend development
tools were way more advanced and easy to use than anything available for
free in the Linux world.  The downside was having to program in VBA but
things may be much better these days with .NET et.al.



Re: Recomended front ends?

From
Adrian Klaver
Date:
On 8/8/19 9:55 AM, Stuart McGraw wrote:
> On 8/7/19 2:38 PM, Rich Shepard wrote:
>> On Wed, 7 Aug 2019, Igor Korot wrote:
>>
>>> On top of what already been said - make sure that the product you are
>>> about to start working on will have its requirements clear and concise.
>>
>> This is a critical process that needs to be developed in depth. One
>> criterion that will guide your choice of UI is whether the database 
>> will be
>> accessed only on the LAN or also remotely. For the former, consider using
>> Python3 + psycopg + SQLAlchemy. For the latter, consider a web-based
>> application using Django.
>>
>> HTH,
>>
>> Rich
> 
> I would be a little cautious about Django.  Last time I checked,
> like many other web frameworks, it treats the database as just another
> component, one that provides data persistence for it, and consequently
> imposes its own constraints the schemas it will work with.  Specifically
> IIRC it insists that tables have a single-column primary keys.  If the
> client's existing database is already designed this way then that may
> not be a problem but if it has composite PKs then another option may
> be better.

Agreed the single-column PK is an annoyance, though it can be mitigated 
with unique_together.

The real annoyance is:
https://docs.djangoproject.com/en/1.11/ref/models/fields/#primary-key
"The primary key field is read-only. If you change the value of the 
primary key on an existing object and then save it, a new object will be 
created alongside the old one."

That being said I use Django with managed set to False on models and 
Sqitch doing the schema changes with no problems. Also Postgres is the 
reference database for Django and has a contrib module with Postgres 
specific features:
https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/


> 
> Flask is another relatively easy to use framework, can be used with or
> without Sqlalchemy but doesn't have the wealth of addons available with
> Django and being simpler requires more work to build the end application.
> There are of course many other framework options (Bottle, Web2Py, etc)
> 
> Although it's been a decade plus since I worked with Microsoft products
> I had fairly good luck back then using Microsoft Access / VBA connected
> to a Postgresql backend via ODBC.  Even back then MS's frontend development
> tools were way more advanced and easy to use than anything available for
> free in the Linux world.  The downside was having to program in VBA but
> things may be much better these days with .NET et.al.
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



Re: Recomended front ends?

From
Rich Shepard
Date:
On Thu, 8 Aug 2019, Stuart McGraw wrote:

> I would be a little cautious about Django.

> Specifically IIRC it insists that tables have a single-column primary
> keys.

Stuart,

I looked seriously at Django and did not encounter that limitation. However,
I did learn that I'm not a web application developer nor do I want to be.
The applications I develop, primarily for my own business needs. use
SQLAlchemy and that allows multi-column primary keys. That's a necessity for
many-to-many tables (or SA classes).

I suspect that Django also allows multi-column primary keys but the syntax
might not be obvious.

Regards,

Rich



Re: Recomended front ends?

From
Adrian Klaver
Date:
On 8/8/19 10:34 AM, Rich Shepard wrote:
> On Thu, 8 Aug 2019, Stuart McGraw wrote:
> 
>> I would be a little cautious about Django.
> 
>> Specifically IIRC it insists that tables have a single-column primary
>> keys.
> 
> Stuart,
> 
> I looked seriously at Django and did not encounter that limitation. 
> However,
> I did learn that I'm not a web application developer nor do I want to be.
> The applications I develop, primarily for my own business needs. use
> SQLAlchemy and that allows multi-column primary keys. That's a necessity 
> for
> many-to-many tables (or SA classes).
> 
> I suspect that Django also allows multi-column primary keys but the syntax
> might not be obvious.

Unfortunately it does not:
https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys

Given that the issue:

https://code.djangoproject.com/ticket/373

is 14 years old does not inspire confidence that it will change anytime 
soon.

> 
> Regards,
> 
> Rich
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



Re: Recomended front ends?

From
Rich Shepard
Date:
On Thu, 8 Aug 2019, Adrian Klaver wrote:

> Unfortunately it does not:
> https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys
>
> Given that the issue:
> https://code.djangoproject.com/ticket/373
> is 14 years old does not inspire confidence that it will change anytime soon.

Adrian,

That's really interesting. I don't see how a framework cannot implement
multi-column PKs.

Many databases I have include tables for samples (geochemical, biological,
physical) where the PK for each row is location, date, parameter. Good thing
I don't like browser user interfaces, eh? :-)

Thanks for the information,

Rich




Re: Recomended front ends?

From
Tim Clarke
Date:
On 08/08/2019 17:55, Stuart McGraw wrote:
>
> I would be a little cautious about Django.  Last time I checked,
> like many other web frameworks, it treats the database as just another
> component, one that provides data persistence for it, and consequently
> imposes its own constraints the schemas it will work with. Specifically
> IIRC it insists that tables have a single-column primary keys.  If the
> client's existing database is already designed this way then that may
> not be a problem but if it has composite PKs then another option may
> be better.
>
> Flask is another relatively easy to use framework, can be used with or
> without Sqlalchemy but doesn't have the wealth of addons available with
> Django and being simpler requires more work to build the end application.
> There are of course many other framework options (Bottle, Web2Py, etc)
>
> Although it's been a decade plus since I worked with Microsoft products
> I had fairly good luck back then using Microsoft Access / VBA connected
> to a Postgresql backend via ODBC.  Even back then MS's frontend
> development
> tools were way more advanced and easy to use than anything available for
> free in the Linux world.  The downside was having to program in VBA but
> things may be much better these days with .NET et.al.


We tried Django without any pleasant results.

I'd also caution using MS Access, we're desperate to get away from it.
Sharing code has challenges and it is horribly aggressive with caching
unless you use un-bound forms and write all the CRUD interface code
yourself.

Tim Clarke



Telephone: Witham: +44(0)1376 503500 | London: +44 (0)20 3009 0853 | Frankfurt: +49 (0)69 7191 6000 | Hong Kong: +852
58031687 | Toronto: +1 647 503 2848
 
Web: https://www.manifest.co.uk/



Minerva Analytics Ltd - A Solactive Company
9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | United Kingdom

________________________________

Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee
youmust not use or disclose such information, instead please report it to
admin@minerva.info<mailto:admin@minerva.info>
Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd: Registered in England Number 11260966 & The
ManifestVoting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here
https://www.manifest.co.uk/legal/for further information.
 

Re: Recomended front ends?

From
Andrew Kerber
Date:


On Thu, Aug 8, 2019 at 1:30 PM Tim Clarke <tim.clarke@minerva.info> wrote:
On 08/08/2019 17:55, Stuart McGraw wrote:
>
> I would be a little cautious about Django.  Last time I checked,
> like many other web frameworks, it treats the database as just another
> component, one that provides data persistence for it, and consequently
> imposes its own constraints the schemas it will work with. Specifically
> IIRC it insists that tables have a single-column primary keys.  If the
> client's existing database is already designed this way then that may
> not be a problem but if it has composite PKs then another option may
> be better.
>
> Flask is another relatively easy to use framework, can be used with or
> without Sqlalchemy but doesn't have the wealth of addons available with
> Django and being simpler requires more work to build the end application.
> There are of course many other framework options (Bottle, Web2Py, etc)
>
> Although it's been a decade plus since I worked with Microsoft products
> I had fairly good luck back then using Microsoft Access / VBA connected
> to a Postgresql backend via ODBC.  Even back then MS's frontend
> development
> tools were way more advanced and easy to use than anything available for
> free in the Linux world.  The downside was having to program in VBA but
> things may be much better these days with .NET et.al.


We tried Django without any pleasant results.

I'd also caution using MS Access, we're desperate to get away from it.
Sharing code has challenges and it is horribly aggressive with caching
unless you use un-bound forms and write all the CRUD interface code
yourself.

Tim Clarke



Telephone: Witham: +44(0)1376 503500 | London: +44 (0)20 3009 0853 | Frankfurt: +49 (0)69 7191 6000 | Hong Kong: +852 5803 1687 | Toronto: +1 647 503 2848
Web: https://www.manifest.co.uk/



Minerva Analytics Ltd - A Solactive Company
9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | United Kingdom

________________________________

Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee you must not use or disclose such information, instead please report it to admin@minerva.info<mailto:admin@minerva.info>
Legal: Minerva Analytics is the trading name of: Minerva Analytics Ltd: Registered in England Number 11260966 & The Manifest Voting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here https://www.manifest.co.uk/legal/ for further information.

You might look at Benthic SQLall.
--
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Re: Recomended front ends?

From
Rich Shepard
Date:
On Thu, 8 Aug 2019, Tim Clarke wrote:

> We tried Django without any pleasant results.

Tim,

That's unexpected and too bad.

> I'd also caution using MS Access, we're desperate to get away from it.
> Sharing code has challenges and it is horribly aggressive with caching
> unless you use un-bound forms and write all the CRUD interface code
> yourself.

Slightly off-topic, but I've not seen anything good about Access. My
understanding is it's a flat-file database intended as a user front end to
Microsoft's relational database product. My experiences with those who use
it have been painful.

Just yesterday I downloaded a very large database of fisheries data from a
federal agency and have started translating it to postgres using the
mdbtools. There's no schema provided, only 32 pages of table columns and
types without descriptions of the column names. No primary keys, no foreign
keys, and only 66 tables were found in the .mdb file while all table names
starting with s through z were not available. There are also many tables
that hold redundant data which should not exist as the contents are easily
generated by SQL queries. It will take me a while to make it a working
relational database.

Rich




Re: Recomended front ends?

From
"Basques, Bob (CI-StPaul)"
Date:
All,

No Web driven, but . . . . we’ve had some success with using LibreOffice(calc) as a frontend.  Fairly easy to build
forms,etc.  Only limited experience so far, but was able to build domain lists from SQL calls, for form pulldown lists,
etc.
 

bobb


> On Aug 8, 2019, at 2:10 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
> 
> Think Before You Click: This email originated outside our organization.
> 
> 
> On Thu, 8 Aug 2019, Tim Clarke wrote:
> 
>> We tried Django without any pleasant results.
> 
> Tim,
> 
> That's unexpected and too bad.
> 
>> I'd also caution using MS Access, we're desperate to get away from it.
>> Sharing code has challenges and it is horribly aggressive with caching
>> unless you use un-bound forms and write all the CRUD interface code
>> yourself.
> 
> Slightly off-topic, but I've not seen anything good about Access. My
> understanding is it's a flat-file database intended as a user front end to
> Microsoft's relational database product. My experiences with those who use
> it have been painful.
> 
> Just yesterday I downloaded a very large database of fisheries data from a
> federal agency and have started translating it to postgres using the
> mdbtools. There's no schema provided, only 32 pages of table columns and
> types without descriptions of the column names. No primary keys, no foreign
> keys, and only 66 tables were found in the .mdb file while all table names
> starting with s through z were not available. There are also many tables
> that hold redundant data which should not exist as the contents are easily
> generated by SQL queries. It will take me a while to make it a working
> relational database.
> 
> Rich
> 
> 
> 


Re: Recomended front ends?

From
DiasCosta
Date:
Hi,
After many years of using Oracle Forms and Oracle Reports with Oracle DB, I have been using Lazarus and "Code Typhon"

for many years now.
Both work with Free Pascal Compiler and both are open source and free.
Both have a very good IDE, the code produced is Pascal (very easily readable), and they connect directly to many DBMS including PostgreSQL, Oracle,  MSSQL, SQLITE, etc.
.

You can find information here:  https://en.wikipedia.org/wiki/Lazarus_(IDE)
and here:  https://www.pilotlogic.com/sitejoom/

Also here:   https://en.wikipedia.org/wiki/Lazarus_(IDE)
you can find some interesting information.

Also here:   https://www.getlazarus.org/learn/tutorials/intro/
"If you are haven't used Lazarus recently then this tutorial is for you. In it we give users a broad overview of Lazarus
and some of its key features. We look at the type of applications you can create with Lazarus, and show you the core
concepts to desktop application development it makes so very easy.
Highlights include the two way design process, events handlers, testing and debugging, and deployment.
A brief gallery of applications I've personally created with Lazarus is included at the end, and I honestly believe it's
the best tool in the world for developing platform agnostic desktop applications. Like the video says, give Lazarus a try."


Dias Costa









On 08-08-2019 20:26, Basques, Bob (CI-StPaul) wrote:
All,

No Web driven, but . . . . we’ve had some success with using LibreOffice(calc) as a frontend.  Fairly easy to build forms, etc.  Only limited experience so far, but was able to build domain lists from SQL calls, for form pulldown lists, etc. 

bobb


On Aug 8, 2019, at 2:10 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

Think Before You Click: This email originated outside our organization.


On Thu, 8 Aug 2019, Tim Clarke wrote:

We tried Django without any pleasant results.
Tim,

That's unexpected and too bad.

I'd also caution using MS Access, we're desperate to get away from it.
Sharing code has challenges and it is horribly aggressive with caching
unless you use un-bound forms and write all the CRUD interface code
yourself.
Slightly off-topic, but I've not seen anything good about Access. My
understanding is it's a flat-file database intended as a user front end to
Microsoft's relational database product. My experiences with those who use
it have been painful.

Just yesterday I downloaded a very large database of fisheries data from a
federal agency and have started translating it to postgres using the
mdbtools. There's no schema provided, only 32 pages of table columns and
types without descriptions of the column names. No primary keys, no foreign
keys, and only 66 tables were found in the .mdb file while all table names
starting with s through z were not available. There are also many tables
that hold redundant data which should not exist as the contents are easily
generated by SQL queries. It will take me a while to make it a working
relational database.

Rich





-- 
J. M. Dias Costa
Telef. 214026948     Telem. 939307421

Se divulgar esta mensagem por terceiros, por favor:
1. Apague o meu endereço de correio electrónico e o meu nome.
2. Apague também os endereços dos seus amigos antes de distribuir.
3. Enderece como cópia oculta (Cc ou Bcc) para os SEUS destinatários.
Agindo deste modo, dificultará a disseminação de "vírus", "spams" e
"banners" e contribuirá para manter a privacidade de todos e cada um.
Obrigado.

Nota: Não se deverá ao acaso a ocorrência de palavras na minha escrita que não respeitem o 
malfadado acordo ortográfico.

Re: Recomended front ends?

From
Paolo Saudin
Date:
For web/mobile applications we use Mojolicious, https://mojolicious.org witch work pretty well with Postgresql, is written in Perl and has plenty of nice features.
Paolo Saudin

Il giorno gio 8 ago 2019 alle ore 22:09 DiasCosta <diascosta@diascosta.org> ha scritto:
Hi,
After many years of using Oracle Forms and Oracle Reports with Oracle DB, I have been using Lazarus and "Code Typhon"

for many years now.
Both work with Free Pascal Compiler and both are open source and free.
Both have a very good IDE, the code produced is Pascal (very easily readable), and they connect directly to many DBMS including PostgreSQL, Oracle,  MSSQL, SQLITE, etc.
.

You can find information here:  https://en.wikipedia.org/wiki/Lazarus_(IDE)
and here:  https://www.pilotlogic.com/sitejoom/

Also here:   https://en.wikipedia.org/wiki/Lazarus_(IDE)
you can find some interesting information.

Also here:   https://www.getlazarus.org/learn/tutorials/intro/
"If you are haven't used Lazarus recently then this tutorial is for you. In it we give users a broad overview of Lazarus
and some of its key features. We look at the type of applications you can create with Lazarus, and show you the core
concepts to desktop application development it makes so very easy.
Highlights include the two way design process, events handlers, testing and debugging, and deployment.
A brief gallery of applications I've personally created with Lazarus is included at the end, and I honestly believe it's
the best tool in the world for developing platform agnostic desktop applications. Like the video says, give Lazarus a try."


Dias Costa









On 08-08-2019 20:26, Basques, Bob (CI-StPaul) wrote:
All,

No Web driven, but . . . . we’ve had some success with using LibreOffice(calc) as a frontend.  Fairly easy to build forms, etc.  Only limited experience so far, but was able to build domain lists from SQL calls, for form pulldown lists, etc. 

bobb


On Aug 8, 2019, at 2:10 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

Think Before You Click: This email originated outside our organization.


On Thu, 8 Aug 2019, Tim Clarke wrote:

We tried Django without any pleasant results.
Tim,

That's unexpected and too bad.

I'd also caution using MS Access, we're desperate to get away from it.
Sharing code has challenges and it is horribly aggressive with caching
unless you use un-bound forms and write all the CRUD interface code
yourself.
Slightly off-topic, but I've not seen anything good about Access. My
understanding is it's a flat-file database intended as a user front end to
Microsoft's relational database product. My experiences with those who use
it have been painful.

Just yesterday I downloaded a very large database of fisheries data from a
federal agency and have started translating it to postgres using the
mdbtools. There's no schema provided, only 32 pages of table columns and
types without descriptions of the column names. No primary keys, no foreign
keys, and only 66 tables were found in the .mdb file while all table names
starting with s through z were not available. There are also many tables
that hold redundant data which should not exist as the contents are easily
generated by SQL queries. It will take me a while to make it a working
relational database.

Rich





-- 
J. M. Dias Costa
Telef. 214026948     Telem. 939307421

Se divulgar esta mensagem por terceiros, por favor:
1. Apague o meu endereço de correio electrónico e o meu nome.
2. Apague também os endereços dos seus amigos antes de distribuir.
3. Enderece como cópia oculta (Cc ou Bcc) para os SEUS destinatários.
Agindo deste modo, dificultará a disseminação de "vírus", "spams" e
"banners" e contribuirá para manter a privacidade de todos e cada um.
Obrigado.

Nota: Não se deverá ao acaso a ocorrência de palavras na minha escrita que não respeitem o 
malfadado acordo ortográfico.

Re: Recomended front ends?

From
"Peter J. Holzer"
Date:
On 2019-08-08 10:47:47 -0700, Rich Shepard wrote:
> On Thu, 8 Aug 2019, Adrian Klaver wrote:
> > Unfortunately it does not:
> > https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys
> >
> > Given that the issue:
> > https://code.djangoproject.com/ticket/373
> > is 14 years old does not inspire confidence that it will change anytime soon.
>
> Adrian,
>
> That's really interesting. I don't see how a framework cannot implement
> multi-column PKs.

You are a database guy. You have a database and want to write an
application for it. Even in a greenfield project, you probably do the
database design first. (I know I do)

The Django framwork comes from the opposite direction. The programmers
aren't expected to know much about relational databases[1]. They are
expected to write their application and Django provides (among other
things like session and form handling) a persitence layer which happens
to be backed by a relational database.

So Django's ORM layer isn't intended to deal with any possible (or even
any reasonable) database model - just with database models generated by
Django.

Django lets you use "unmanaged" tables, but it is quite noticeable that
this isn't the primary use case.

> Many databases I have include tables for samples (geochemical, biological,
> physical) where the PK for each row is location, date, parameter. Good thing
> I don't like browser user interfaces, eh? :-)

Django isn't the only web framework.

        hp

[1] It should be noted, however, that the Django ORM is what Joel
    Spolsky calls a leaky abstraction. If you are ignorant about how
    RDBMSs work, your application will probably be horrendously slow.
    Even if you do know this, you often have to bend over backwards to
    get reasonable performance.

--
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp@hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

Attachment

Re: Recomended front ends?

From
Daniele Varrazzo
Date:
On Sun, Aug 11, 2019 at 7:49 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote:

> Django lets you use "unmanaged" tables, but it is quite noticeable that
> this isn't the primary use case.

It isn't, but it's the best way to use Django for database-literate
people. It's enough to ignore the Django sale pitch of the database as
a replaceable element and just assume Postgres. In Docker times you
don't need SQLite to create a poorly representative "development
database".

You can just ignore the Django ORM for the whole data-definition layer
and migrations: you can have your database schema, with comments, in
your source code, with strict control of what's in the db (exotic
index definitions, exclusion constraints, writable views...) and only
use the ORM to read and manipulate data, as long as the Django model
"resembles" the database table.
Schema migrations are easy to deal with using SQL patches [1], and
complete, unlike any Model-based migration system.

Using the Django ORM to create complex queries is a joy (especially
nesting subqueries), and you don't lose all the other Django
facilities (decent auth model, decent CRUD interface, customisation
when "decent" is not enough).

[1] https://gist.github.com/dvarrazzo/4161070

-- Daniele



Re: Recomended front ends?

From
Adrian Klaver
Date:
On 8/27/19 8:04 AM, Daniele Varrazzo wrote:
> On Sun, Aug 11, 2019 at 7:49 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
> 
>> Django lets you use "unmanaged" tables, but it is quite noticeable that
>> this isn't the primary use case.
> 
> It isn't, but it's the best way to use Django for database-literate
> people. It's enough to ignore the Django sale pitch of the database as
> a replaceable element and just assume Postgres. In Docker times you
> don't need SQLite to create a poorly representative "development
> database".

Django takes Postgres as it's reference database which makes things 
easier, especially when you add in 
contrib.postgres(https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/)


> 
> You can just ignore the Django ORM for the whole data-definition layer
> and migrations: you can have your database schema, with comments, in
> your source code, with strict control of what's in the db (exotic
> index definitions, exclusion constraints, writable views...) and only
> use the ORM to read and manipulate data, as long as the Django model
> "resembles" the database table.
> Schema migrations are easy to deal with using SQL patches [1], and
> complete, unlike any Model-based migration system.

+1

> 
> Using the Django ORM to create complex queries is a joy (especially
> nesting subqueries), and you don't lose all the other Django
> facilities (decent auth model, decent CRUD interface, customisation
> when "decent" is not enough).
> 
> [1] https://gist.github.com/dvarrazzo/4161070
> 
> -- Daniele
> 
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



Re: Recomended front ends?

From
"Peter J. Holzer"
Date:
On 2019-08-27 16:04:02 +0100, Daniele Varrazzo wrote:
> Using the Django ORM to create complex queries is a joy (especially
> nesting subqueries),

Not for me. I usually know what SQL I want to execute. Then I have to
convert that SQL into a weird[1] and limited query language composed of
method calls so that the ORM can turn it into SQL again (hopefully
something close to the SQL I had in mind). It hurts my brain.

        hp

[1] Well, SQL is weird, too. But it is weird in an "invented 40+ years
ago and grown organically since" way, not a "constrained by the syntax
of a different language" way.


--
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp@hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

Attachment

Re: Recomended front ends?

From
"Peter J. Holzer"
Date:
On 2019-08-27 08:16:08 -0700, Adrian Klaver wrote:
> Django takes Postgres as it's reference database which makes things easier,
> especially when you add in
> contrib.postgres(https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/)

Looks nice.

        hp

--
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp@hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

Attachment