|
On 16-Jul-2016 18:06 -0500, CRPence wrote:
On 15-Jul-2016 13:58 -0500, Troy Hyde wrote:
On 15-Jul-2016 09:16 -0500, CRPence wrote:
On 14-Jul-2016 17:25 -0500, Troy Hyde wrote:
One of our web programmers is creating a page that contains
among other things, a description of printers including the
IP address. She has been able to obtain all of the
information she needs via SQL except the IP address. <<SNIP>>
What SQL is currently being used to provide the information
about printer devices; i.e. what invocation provides the DEVD
information without including the IP address? <<SNIP>>
We have a configuration table in our package that has a row for
each printer. It contains information specific for our
workflows: headings, lines to advance, next check number, print
logo, etc, etc. All of the information that she has been asked to
put on the screen is contained in this table except the I.P.
address of the printer. That one piece of information is not
specific to our package but specific to the *DEVD. We could put
it in the table (and we probably will,) but that would mean that
if someone changes the device description _without_ changing the
table, the information is incorrect. <<SNIP>>
I see how dynamic reflection is probably better than trying to
store and maintain the value; avoiding the need to ensure
consistency between the actual device attribute and the
representation of that attribute in row data. Note however, that
there is the capability to intercept the [return from] the [Create
and\or the] Change Device Description {Printer} (CHGDEVPRT)
command(s); that could be used as a means to enable maintaining
accuracy between the device and the row data <<SNIP>>
The original poster's real problem is that one set of experts is
trying to figure a way to communicate with another set of experts.
That is, ExpertsA are dynamically looking to determine the IP
Address of specific printers, as assigned by ExpertsB.
That wheel has been invented. For this problem it's called DNS. The
DNS specifies the IP Address attached to a specific name. Standard
stuff, easily configurable, understood by everyone involved.
Why would anyone look to invent some new poorly understood solution?
(I say poorly understood because it's pretty clear from the various
postings.)
200 lines of text?!?! Good grief!! I had no idea you would append
that many lines to one of your responses,
Chuck. In the future I will check your replies and remove the
extraneous lines for you. Sorry; please accept my apologies.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.