Has anyone developed an MV database-independent library for PHP that
works with at least U2 and OpenQM? --dawn

"dawn" wrote:
When running over Windows, PHP can use COM objects. So if you don't
have "native" PHP DBMS connectivity for a specific DBMS you can use
tools that are already available like UO or the D3 Class Library.
Specific to your "database-independent" query, note that mv.NET does
work with a wide variety of databases, and can be enhanced to work
with others based on demand. So...
PHP <> COM <> COM Interop <> mv.NET <> any MV DBMS

Again, the DBMS can be running on any OS, the other parts need to be
running in Windows.

If you're running PHP on a *nix web server, another way to do this is
to use Web Services from PHP to make a request to a Windows box that's
using whatever tools you're comfortable with. So... You can use the
above architecture, calling from PHP/*nix to PHP/Win. You can replace
the COM layer later as better options come available without
disturbing your web code (very MVC-friendly).
The Windows box doesn't need to be exposed to the net, a low-profile
box on the LAN is all that's required.

Abstracting even further (and I hope I haven't lost anyone), you can
write your own data access layer and use this as an abstraction from
your PHP application code, so that for example, you go direct into QM
but you use a Web Service to get into U2. Diagram:
PHP <> Data access abstraction <> platform-specific access

When comparing the cost of development vs the cost of purchase,
consider that what you're asking for is available starting at about
US$250. If you have an end-user that needs a solution "soon" then you
might want to consider this sort of architecture as an interrim
solution, as you seek or build something else.

These same techniques can be used for any language or platform
including Java, Perl, Ruby, etc.

Feel free to contact me off-list for more info.
Tony
TG @ removethisNebula-RnD .com

It might be interesting to hear from John Lombardo on this.

the interest is that php is like proc

michael (AT) preece (DOT) net wrote:
Mike, please correct me if I'm wrong but I think you're referring to
this Perl code that John posted to CDP, not PHP:
http://tinyurl.com/dv9lf

Jumping in because I believe John has a real job these days, in a
non-MV environment. He probably doesn't visit CDP much anymore.
Could be wrong...

T

Tony Gravagno wrote:

Too bad. Just *look* at everything he's missing. ;-)

--
Kevin Powick

Glen B wrote:
And I realize it is a new spin on an old question.

I would like an API usable from within PHP for CRUD services where I
could specify a data source of any of the MV platforms. Additionally,
I would like performance to be great with scalability on each platform.
I'm sure I'm missing some requirements, but you get the idea ;-)

You have mentioned before that you have cross-platform connectivity --
can you point me to anything about it?

If all work with asynch with the UI, that might help mitigate some of
the loss of speed.

Some of it made sense to me. I have worked with UOJ, which needed
connection pooling to scale (which they have with the latest release
for a price). I have also worked with ODBC. But I have not written
any such driver and I have not worked on being cross-platform before,
so you know a lot more than I do about this. Thanks. --dawn

Tony Gravagno wrote:

I don't know why I get a 403 (forbidden by proxy) here when I try to
take that link but I do. A quick google of CDP for Lombardo & perl
showed 2 or three candidate postings. I wasn't actually referring to
any post in particular though. I never really understood why John was
giving us those perls of wisdom btw. Why not just use FC as is and do
things inside Pick? Sorry if that recurring theme is beginning to grate
- but it's how I think. Show me the error of my ways and I'll stop
making the mistake - if that's what it is.

<major point>Pick is a application server and a DBMS in one</major
point>

It's more that I took a fairly (OK - very) free interpretation on the
subject line - and took it to mean "How do we connect a web-server to
any MV flavour to run PickBasic subroutines/applications just like we
do with FlashCONNECT - with all of the 'extras' that come with FC -
maybe using PHP?" - and thought what a shame it is that the work John
did in porting FC to UniVerse (with plans for UniData & jBase too),
back in the day, was very likely wasted while RD wait for a business
case to roll it out. How will people (other than those who have "seen
the FC light") know it's any good if it's never released? A bit of a
catch-22 that.

John seems to me to be the best independent person, possibly along with
Doug Dumitru, to talk about authoring tools for connecting things on
the web-server with Pick - afaik. Where John's and Doug's approaches
differ is that John "plugged stuff in" to existing web-servers and Doug
took over and wrote a Pick web-server himself. Personally, I prefer
John's approach. Why? Well - it's similar to the reason we (at HHH)
went with FC rather than try to DIY. Let someone else take
responsibility for any "issues" and keep abreast of, or forge ahead in,
new developments in web-server technology. FC is, was, and is likely to
remain, an excellent way to connect web-severs to Pick. Just a shame
it's not free - as it once was - and that the plans to roll out
versions across all MV flavours have been shelved.

Mike.

PS. I hope you don't feel left out by the above Tony. You seem to me to
be really good at getting the best out of existing tools. I'm assuming
John and Doug are better at writing code to build tools. I'm not
confident in this belief though - you've proved yourself to be very
clever.

michael (AT) preece (DOT) net wrote:
All else acknowledged, I just wanted to respond to this last part.
When FC was free people didn't care any more than they do now, so
"free" doesn't seem to be a factor in it's acceptance. There are some
products that cost less than FC and others that cost more, success
doesn't seem to depend entirely on cost. I think it's more a matter
of marketing and public awareness - squeaky wheel gets the grease, so
to speak. FC was never marketed properly, no real drive to get people
to use it. Like all of RD's products it was just put out there and
PS/RD expects people to adopt it all on their own initiative. Even
now I'm tutoring a developer on how to use FC because there is
virtually no other information available for navigating this fine
product. This is precisely the reason why I wanted to do all of those
demos for WUC 2000, to open people's eyes to the possibilities. If RD
had marketed FC across platforms the same way they marketed to the D3
user base then it would have been a dud anyway, so maybe it's better
that they didn't even try.

And FC is only $1500 for end-users and still comes free with D3
developer licenses. If a VAR can sell their application to a new
audience of people that wants a web UI instead of telnet clients then
this is a small price to roll into the total product price - same goes
for any for-fee or for-free tools we discuss here. A non-persistent
web interface can be especially economical for end-users considering
the multiple client/license usage model which makes these web
solutions less expensive for the end-user than the persistent user,
per-seat model. So I've never been able to see how even at $1500 that
people can complain about price.

No offense taken Mike, you're right, I don't pretend to be in their
calibre and I respect them both immensely. John and Doug have spent a
lot of time building tools in *nix with C and assembler. I never
enjoyed C or assembler (BAL or PA) and prefer to work with existing
tools at higher tiers of abstraction. Thanks for the nod.

T