On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhřj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic?
If you want to write business applications, then either Java or a subset
of C++. C++ subset to be chosen based on programmer skillsets and the
problem to be solved.
If you want to write modern-day CUSPs, then either C or C++.
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.
There are other areas that BASIC was never suitable for, such as number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from something like Python.
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic?
There are multiple languages that have left BASIC in the dust.
If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.
There are other areas that BASIC was never suitable for, such as
number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from something like Python. There are also higher-level languages such as
MATLAB or Octave that can be used here as well.
On Thu, 11 Jan 2024 18:30:07 -0000 (UTC), Simon Clubley wrote:
If you want to write business applications, then either Java or a subset
of C++. C++ subset to be chosen based on programmer skillsets and the
problem to be solved.
Kotlin is an open-source alternative to Java that does not have Oracle’s rapacious fingers all over it. Google has been adopting it for Android development, for example.
On 1/11/2024 1:30 PM, Simon Clubley wrote:
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
Or COBOL which was actually designed for the task.
On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
On 1/11/2024 1:30 PM, Simon Clubley wrote:
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
Or COBOL which was actually designed for the task.
Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for “business applications” in COBOL. So it had to resort to nonstandard kludges tacked to the side to cope with SQL queries.
It wasn't difficulty to interface DEC Basic to a DB.
And string handling is every bit as good as any other language.
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhřj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by.
I confess to curiosity. In what ways has other languages passed by Basic? >>
There are multiple languages that have left BASIC in the dust.
If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
If you want to write modern-day CUSPs, then either C or C++.
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.
There are other areas that BASIC was never suitable for, such as
number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from something like Python. There are also higher-level languages such as
MATLAB or Octave that can be used here as well.
BTW, Octave is available here if you want to look:
https://octave.org/
Simon.
On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
On 1/11/2024 1:30 PM, Simon Clubley wrote:
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
Or COBOL which was actually designed for the task.
Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for “business applications” in COBOL. So it had to resort to nonstandard kludges tacked to the side to cope with SQL queries.
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of momentum
and never was a big success outside of the academic field, which used to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?
I'm still doing all my programming in Pascal... Now that I'm retired, no
one else at my former work uses it anymore. They keep a one user license
to maintain my code, if it is ever needed. But I'm afraid this compiler
will feel very lonely...
On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
On 1/11/2024 1:30 PM, Simon Clubley wrote:
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
Or COBOL which was actually designed for the task.
Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for “business applications” in COBOL. So it had to resort to nonstandard kludges tacked to the side to cope with SQL queries.
On Thu, 11 Jan 2024 22:38:55 -0500, bill wrote:
And string handling is every bit as good as any other language.
Here, in Python, is the kind of dynamically-varying filter criteria I
did for a search function in one application. Note the inclusion of
field match checks only for fields where the user entered something:
Have you ever managed anything similar in COBOL?
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of
momentum
and never was a big success outside of the academic field, which used
to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?
Den 2024-01-12 kl. 02:56, skrev Lawrence D'Oliveiro:
On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
On 1/11/2024 1:30 PM, Simon Clubley wrote:
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
Or COBOL which was actually designed for the task.
Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And >> the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.
Well, that is written by someone without a clue.
Building SQL queries using string operations is a no-no
for any professional database development.
It does mean that
the whole SQL syntax check and compilation has to be done by
the run time environment. And if some parameter changes (like
an order number), the whole query is concidered to be "new" and
the full syntax check and compilation is done again each time.
For applications developed on, and running on, VMS there are two
main options:
Embedded SQL.
Supported by most common languages. When building an application here,
a pre-compiler is first run. That one extracts all SQL statements and compiles the SQL into object/machine code. When the main compiler is
then run, this object code is automaticaly included in the main object
file.
SQL Modular Language.
This is a bit similar to Embedded SQL, but the SQL code is kept in
a separate file by itself. And the SQLMOD compiler only reads this
file and creates a stand-alone object file. This object file is then
just included in the build of the main application. The main application
just calls some functions with any name (like "GetOrder") and it
(the main code) has no idea that there is any SQL or database or how
that order data is fetched. So it can be used from any compiled language
no matter if that specific language have any specific SQL support.
For Cobol both these options exists. They can be mixed anyway in the same application, if needed. We had some common queries (like "FetchOrder") as SQLMOD files and then added the specific application queries into the application code as Embedded SQL for easier maintenance of the code.
So, the bottom line is, that there is absolutely no need for any
string operations to use SQL from Cobol applications.
And, as Arne also mentioned, there is a huge security issue with
bulding SQL queries using string operations, if you include any
dynamic parameters into that.
If you need to use dynamically built SQL queries, at least use what
is commonly called "parameter markers", where the main SQL code and
the values of any parameters are separated from each other. That way
you cannot include any non-wanted SQL code in the actual values of
the paramaters.
On 2024-01-12, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of
momentum
and never was a big success outside of the academic field, which used
to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?
Pascal is a dead language for most new development. Unfortunately.
VSI released the compilers in order of customer usage and there is still
a large base of existing Pascal source code that needs to be able to
run on x86-64 VMS.
But VB.NET is reasonable uptodate.
On Thu, 2024-01-11 at 19:22 -0500, Arne Vajhøj wrote:
But VB.NET is reasonable uptodate.
Oh yes, it does work, that's for sure. But new things are now only
going in for C#.
On 12/01/2024 13:03, Single Stage to Orbit wrote:
On Thu, 2024-01-11 at 19:22 -0500, Arne Vajhøj wrote:
But VB.NET is reasonable uptodate.
Oh yes, it does work, that's for sure. But new things are now only
going in for C#.
I thought new things went into the .net bit, and then could be called by
any of the languages
On Thu, 2024-01-11 at 19:22 -0500, Arne Vajhøj wrote:
But VB.NET is reasonable uptodate.
Oh yes, it does work, that's for sure. But new things are now only
going in for C#.
On 2024-01-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 11 Jan 2024 22:38:55 -0500, bill wrote:
And string handling is every bit as good as any other language.
Here, in Python, is the kind of dynamically-varying filter criteria I
did for a search function in one application. Note the inclusion of
field match checks only for fields where the user entered something:
[Snip example]
Have you ever managed anything similar in COBOL?
For security reasons, I would have preferred to see that as a
prepared statement instead of as a concatenated SQL statement.
Simon Clubley formulated on Thursday :
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 9:28 PM, bill wrote:
On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
The world has evolved.
Exactly. BASIC also evolved, but better languages have passed it by. >>>>
I confess to curiosity. In what ways has other languages passed by
Basic?
There are multiple languages that have left BASIC in the dust.
If you want an initial teaching language, Python is _absolutely_ the
language you start people off with these days. BASIC is absolutely
dead here, and for very good reason.
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
If you want to write modern-day CUSPs, then either C or C++.
If you want a safety-critical language (for completion only, as BASIC
was never suitable here), then something like Ada.
There are other areas that BASIC was never suitable for, such as
number crunching. Depending on your requirements, knowledge, mindset,
etc, then either stay with Fortran, or drive an analysis package from
something like Python. There are also higher-level languages such as
MATLAB or Octave that can be used here as well.
BTW, Octave is available here if you want to look:
https://octave.org/
Simon.
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of momentum
and never was a big success outside of the academic field, which used to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?
I'm still doing all my programming in Pascal... Now that I'm retired, no
one else at my former work uses it anymore. They keep a one user license
to maintain my code, if it is ever needed. But I'm afraid this compiler
will feel very lonely...
Oh yes, it does work, that's for sure. But new things are now only
going in for C#.
VB.NET got almost all the major stuff.
It is missing some of the latest C# language features, but most
of those are more cute than useful.
On 1/11/2024 8:56 PM, Lawrence D'Oliveiro wrote:
On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
On 1/11/2024 1:30 PM, Simon Clubley wrote:
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets
and the problem to be solved.
Or COBOL which was actually designed for the task.
Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the
scene, and they soon became essential for “business applications”. And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity for
“business applications” in COBOL. So it had to resort to nonstandard
kludges tacked to the side to cope with SQL queries.
Dynamically generating SQL strings is actually a big no no.
That is the road to poor performance and big security holes.
Traditional Cobol embedded SQL does much better than that.
Arne
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore. I understand that it has lost a lot of momentum
and never was a big success outside of the academic field, which used to
be a DEC stronghold way in the past. But in this case, why is VSI (and
before that HPE) still supporting that language today ? It cannot be
customer base, can it ? It is certainly not seen as a language of the
future either... So why ? Just because John likes it, or what ?
On 1/12/2024 7:36 AM, Arne Vajhøj wrote:
On 1/11/2024 8:56 PM, Lawrence D'Oliveiro wrote:
On Thu, 11 Jan 2024 20:25:34 -0500, bill wrote:
On 1/11/2024 1:30 PM, Simon Clubley wrote:
If you want to write business applications, then either Java or a
subset of C++. C++ subset to be chosen based on programmer skillsets >>>>> and the problem to be solved.
Or COBOL which was actually designed for the task.
Supposedly. But a couple of decades after the COBOL spec was first
published, these things called “relational databases” appeared on the >>> scene, and they soon became essential for “business applications”.
And the
best way to access them turned out to require generating SQL query
strings. But good string handling had not been considered a necessity
for
“business applications” in COBOL. So it had to resort to nonstandard >>> kludges tacked to the side to cope with SQL queries.
Dynamically generating SQL strings is actually a big no no.
That is the road to poor performance and big security holes.
Traditional Cobol embedded SQL does much better than that.
SQL is nice. It works. But, I consider it a square hole, and you
better not have a round peg.
For some operations, one must go through rather convoluted things to get
the desired result.
Amazing that in current programming languages discussions, PASCAL is
never mentioned anymore.
For security reasons, I would have preferred to see that as a prepared statement instead of as a concatenated SQL statement.
SQL is nice. It works. But, I consider it a square hole, and you
better not have a round peg.
For some operations, one must go through rather convoluted things to get
the desired result.
Outside the DEC world, there was UCSD Pascal, with an entirely different
(and incompatible, and less ambitious) set of extensions. That became kind
of a de facto standard in the PC world, with Turbo Pascal copying the same set of extensions, for example.
One project that still lives on is Free Pascal
<https://www.freepascal.org/>, which aims to be compatible with UCSD/
Turbo.
- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the release notes that have never made it to the manual. [I've been doing
lots of doc review lately.]
I wrote a lengthy reply to this to answer your (and others) questions. I don't see it online however. If it doesn't show up at some point,
I'll dig it out of some sent folder and resend.
- I don't see the need to add OO to VMS Pascal. There are several other languages to choose from these days. We have added a feature or two
over the years based on customer requests (the last "big" feature was
my addition of the SELECT/SELECTONE statements patterned after the
BLISS equivalents). With all the discussions around what it means to be
a 64-bit program, perhaps I should get the compiler to be more flexible
with its handling of 32-bit vs 64-bit descriptor forms.
On 1/12/2024 4:20 PM, John Reagan wrote:Beats me, ask the people who want to write those business applications.
- I don't see the need to add OO to VMS Pascal. There are several other
languages to choose from these days. We have added a feature or two
over the years based on customer requests (the last "big" feature was
my addition of the SELECT/SELECTONE statements patterned after the
BLISS equivalents). With all the discussions around what it means to be
a 64-bit program, perhaps I should get the compiler to be more flexible
with its handling of 32-bit vs 64-bit descriptor forms.
Right now the goal of VSI must be to get all the existing
VMS customer to port their existing applications to VMS x86-64.
But what is the plan when that is done?
(not urgent because it will take years)
What will new business applications for VMS be written in?
(we are hoping for such!)
Obviously all the non-native languages (Java, Python, PHP etc. - II don't understand your use of "native"? All of the compilers
still recommend Groovy!) are going to grab the majority.
But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?
I would hate to see that.
I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.
Arne
On 1/12/2024 4:51 PM, Arne Vajhøj wrote:
Obviously all the non-native languages (Java, Python, PHP etc. - I
still recommend Groovy!) are going to grab the majority.
But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?
I don't understand your use of "native"? All of the compilers
generate real instructions and are not interpreted. Did you
forgot to say OO?
I would hate to see that.Implementing an OO model is quite involved. The OO Pascal
I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.
addendum to the standard was limited (no multiple inheritance,
just "mixins") but would still be a beast to implement fully.
It isn't something we can hack over a weekend. People who want
such features will need to write that on the back of a large
stack of $100 bills and send that to VSI.
On 1/12/2024 5:17 PM, John Reagan wrote:
On 1/12/2024 4:51 PM, Arne Vajhøj wrote:
Obviously all the non-native languages (Java, Python, PHP etc. - I
still recommend Groovy!) are going to grab the majority.
But for those wanting native code (and quite some will due
to need to link with old legacy code) will C++ really be
the only choice?
I don't understand your use of "native"? All of the compilers
generate real instructions and are not interpreted. Did you
forgot to say OO?
With native I mean traditional EXE.
Yes - there were an implicit "with modern features:
object oriented, generic and functional".
I would hate to see that.Implementing an OO model is quite involved. The OO Pascal
I would love to see VMS Pascal and VMS Basic being beefed up
with OO, generic and maybe a drizzle of functional.
addendum to the standard was limited (no multiple inheritance,
just "mixins") but would still be a beast to implement fully.
It isn't something we can hack over a weekend. People who want
such features will need to write that on the back of a large
stack of $100 bills and send that to VSI.
I know it is a big task.
But when the number of bug reports starts descending towards zero
and LLVM team releases new C/C++ and Fortran compilers and no Cobol developers want OO, then what are you going to spend time on?
Arne
On 1/12/2024 4:20 PM, John Reagan wrote:
- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual. [I've been doing
lots of doc review lately.]
Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?
On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
On 1/12/2024 4:20 PM, John Reagan wrote:
- And the online Pascal docs will be updated soon (I just finished the
review of the Reference Manual and I'm about done with the User Manual). >>> The revision adds x86 works AND incorporates a bunch of stuff from the
release notes that have never made it to the manual. [I've been doing
lots of doc review lately.]
Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?
Closer to 1 quarter than one month.
On 13/01/2024 16:52, Robert A. Brooks wrote:
On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
On 1/12/2024 4:20 PM, John Reagan wrote:
- And the online Pascal docs will be updated soon (I just finished the >>>> review of the Reference Manual and I'm about done with the User Manual). >>>> The revision adds x86 works AND incorporates a bunch of stuff from the >>>> release notes that have never made it to the manual. [I've been doing >>>> lots of doc review lately.]
Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?
Closer to 1 quarter than one month.
Oh Goody! Will it come with LSE?
On 1/13/2024 7:05 PM, Chris Townley wrote:
On 13/01/2024 16:52, Robert A. Brooks wrote:
On 1/12/2024 4:46 PM, Arne Vajhøj wrote:
On 1/12/2024 4:20 PM, John Reagan wrote:
- And the online Pascal docs will be updated soon (I just finished the >>>>> review of the Reference Manual and I'm about done with the User
Manual).
The revision adds x86 works AND incorporates a bunch of stuff from the >>>>> release notes that have never made it to the manual. [I've been doing >>>>> lots of doc review lately.]
Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?
Closer to 1 quarter than one month.
Oh Goody! Will it come with LSE?
They are unrelated.
LSE still has some issues with exception handling. The problems are somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.
It's on my to-do list, but it's not at the top right now, although
it's close.
On 1/13/2024 7:05 PM, Chris Townley wrote:
On 13/01/2024 16:52, Robert A. Brooks wrote:
On 1/12/2024 4:46 PM, Arne Vajhřj wrote:
On 1/12/2024 4:20 PM, John Reagan wrote:
- And the online Pascal docs will be updated soon (I just finished the >>>>> review of the Reference Manual and I'm about done with the User Manual). >>>>> The revision adds x86 works AND incorporates a bunch of stuff from the >>>>> release notes that have never made it to the manual. [I've been doing >>>>> lots of doc review lately.]
Can you reveal anything about how far out Basic for VMS x86-64 is?
1 day? 1 week? 1 month? 1 quarter?
Closer to 1 quarter than one month.
Oh Goody! Will it come with LSE?
They are unrelated.
LSE still has some issues with exception handling. The problems are
somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha.
It's on my to-do list, but it's not at the top right now, although
it's close.
On Fri, 12 Jan 2024 13:34:53 -0000 (UTC), Simon Clubley wrote:
For security reasons, I would have preferred to see that as a prepared
statement instead of as a concatenated SQL statement.
Feel free to show us how you would write it as same. Can your prepared- statement system cope with variable numbers of fields? Variable field
names? Variable operator selections? All these were present in the
example.
Robert A. Brooks submitted this idea :
LSE still has some issues with exception handling. The problems are
somewhat obscure, but nonetheless a regression from LSE on IA64 and Alpha. >>
It's on my to-do list, but it's not at the top right now, although
it's close.
Oh, if we speak about DECset, what about the other products ? PCA being essentially an alternate debugger, it might cause some issues too,
right ?
On 2024-01-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 12 Jan 2024 13:34:53 -0000 (UTC), Simon Clubley wrote:
For security reasons, I would have preferred to see that as a prepared
statement instead of as a concatenated SQL statement.
Feel free to show us how you would write it as same. Can your prepared-
statement system cope with variable numbers of fields? Variable field
names? Variable operator selections? All these were present in the
example.
I have _never_ had the need to do that. In the real world, you know what
data you want to read or update, and with what selection criteria, at the point you write such code.
On 2024-01-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 12 Jan 2024 13:34:53 -0000 (UTC), Simon Clubley wrote:
For security reasons, I would have preferred to see that as a prepared
statement instead of as a concatenated SQL statement.
Feel free to show us how you would write it as same. Can your prepared-
statement system cope with variable numbers of fields? Variable field
names? Variable operator selections? All these were present in the
example.
I have _never_ had the need to do that.
business apps use DIBOL - Synegy DBL ...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 462 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 86:17:58 |
| Calls: | 9,374 |
| Calls today: | 1 |
| Files: | 13,552 |
| Messages: | 6,089,534 |