Recomended front ends?
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
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.
Show quoted text
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
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
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.
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.
Show quoted text
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
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
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 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.
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.
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.
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
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
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
On Thu, 8 Aug 2019, Adrian Klaver wrote:
Unfortunately it does not:
https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeysGiven 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
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.
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.'
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
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
Show quoted text
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
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 <http://www.lazarus-ide.org> 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
<https://www.getlazarus.org/community/showcase> 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
<https://www.getlazarus.org/setup>."
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.
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:
Show quoted text
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 <http://www.lazarus-ide.org> 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
<https://www.getlazarus.org/community/showcase> 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
<https://www.getlazarus.org/setup>."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> <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. 939307421Se 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.
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/MultipleColumnPrimaryKeysGiven 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]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.. 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.
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/>
