I agree with Glen and Symeon - don't do socket work in the DBMS unless you control the protocol and it's dirt-simple. By far the best way to do this is to create a middle tier using tools that are designed to do this, and communicate with the DBMS as a data source. Glen and Symeon and I have been down this path before. Experience has influenced our recommendation. I hope you can benefit from the time we've spent in this area.
It's not "easy" do do this with other tools, but IMO it is better because the tools are more stable, better supported, and you can get help from a much wider audience, including books and websites. Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development services remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! http://Twitter.com/TonyGravagno > From:Symeon Breen > Personally i would write a middleware tier that did > all the comms, and communicated back to u2 > From: Glen B > ... in most of the MV socket services I've implemented > I either: > > 1) use an inetd/Winetd tool to handle the socket-based > muxing and all you have to do is make simple > command-line calls to routines... _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
