Re: dataformatting in nodeJS SQL interface with IBM db2a

Nathan



well very clever RPG programmers has apparently decided to define all their
columns as CHAR fields instead of VARCHAR in their legacy database and that
will give technical inconsistency if connecters don’t follow the chosen
column design in the DB, so don’t shoot the messenger (the interface) that
does comply to the DB design but shoot the DB designer.



When that is said it is a bad idea to have trailing blanks in a browser
based UI simply because users has to delete characters the can’t see in
order to be able to insert characters in the string otherwise it should
trigger an error because they will try to pass a 40 char long string into a
30 char long result field – what do you think happens in a SQL statement if
you try that?



This not either a question on open access from outside but rather
controlled access between native and PASE and if there wasn’t that you can
forget of every thing that runs in PASE such as PHP, JAVA and all the Open
Source modules available.



And even if there was some form of trimming in the interface (you can code
it in the SQL) you would still have the problem with legacy “numeric” date
fields, booleans thet sometimes are 0/1 and other time Y/N but never
unsupported true/false etc. that is spread all over the IBM I databases.



And in basics there are no difference in repacking/mapping raw DB table
data to either JSON, XML, X.12 etc. – as well as you have to do mapping of
the receivables or does SQL or DB supports raw FORMS encoded data or URL
gets escape sequenses - I hardly believe that - so you have to have a layer
where you do it.

On Mon, Mar 26, 2018 at 7:09 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

It's an eye opener for me to read that developers would just as soon
implement blank trimming in a JavaScript client as opposed to implementing
it in the database "layer", so to speak. To me, this is the kind of
functionality that belongs "in the database" as opposed to "in the
application". So that no matter which client (browser, Node.js, PHP, Ruby,
Java, Python, .Net, whatever), they all are provided the same
functionality.

In the database layer, people could create an SQL view that automatically
trimmed trailing blanks. Or IBM could provide a connection option as
suggested by Niels. But I'm ambivalent to those ideas because I have never
been in favor of providing generic SQL and program call interfaces to
clients, primary due to security concerns.

I favor providing granular web service APIs to clients.

The majority of security services offered by vendors in the IBM i space are
designed to address concerns that are derived from shops that are providing
open pathways to IBM i data and programs. In contrast, my company doesn't
run any host servers on IBM i in our production environment. We don't open
any ports on our firewall for those types of interfaces. That may seem
pedantic to some people. But it gives me some peace of mind just knowing
that those interfaces are simply not provided.




On Mon, Mar 26, 2018 at 9:05 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
wrote:

+1

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.