Thanks for the Info on my Previous Post

Does anyone have a Software Solution that works with D3/NT, the client
wishes to have
two separate machines..

Thanks,

Nick

You mean some sort of Transaction Logging? Where all updates on one system
are also updated on a second system for a "hot-swappable" backup server??

If so, I'm no expert on D3 specifically, but you will almost certainly not
be able to use any generic Windows hardware or software solution to do this.

Regards
Simon
"Nick" <nquinnusa (AT) earthlink (DOT) net> wrote

If you are just talking about D3 being mirrored, then D3 already has a hot
backup feature to keep a separate machine updated with changes to the first.

If you are talking about the whole machine running multiple services, I have
no idea. Maybe some one else does.

regards,

Dale

"Simon Verona" <news (AT) aphroditeuk (DOT) com> wrote

5 thoughts:
-----------
1) I don't think there are any software solutions that will work but
they can certainly be custom written. I'd do it if there was real
demand.
2) Not that you asked, but D3 does not support Clustering as it's
understood in the industry, so disk mirroring is not equal to hot
failover. However, with an n-tier solution, code could be written to
do an auto-failover with minimal interruption.
3) Check with RD to see if D3 8.0 has some solution for this. I doubt
it, but it's worth asking about. Hot backup isn't supported in
pre-8.0 releases over NT but as mentioned in #1 it's do-able.
4) I haven't had any coffee yet today so my answers are more
"nebulous" than normal.
5) I thought you were lucky enough to be retiring away from this...

Tony

"Nick" <nquinnusa (AT) earthlink (DOT) net> wrote:

Sorry Dale, Not On NT,

User does not want XNIX in their shop, any version, so we are stuck with NT

I had hot-backup working on the AIX machines for a bunch of years when they
went to NT, I told them not so lucky...

"mirroring" works only within the Blob on XNIX

Thanks
"Dale Benedict" <dalebspamnotwanted (AT) flightcraft (DOT) ca> wrote

"Semi-Retired" Tony, I still do 30 or so hours a month, and the handicap is
coming down!

My compadre in Bermuda went thru this with RD, got the typical, "You can try
anything you like but we won't support it". Yep, I could write it to, gave
the user a 50K price tag and have the design done. They gulped real hard on
that...

How did you like my new logo to go along with Gus' MV, A "circle and a
slash thru a PC Mouse", "No mousie mousie here!"

We still have not gui-ized a thing except some simple wintegrate stuff, no
complaints yet as we are still the fastest data entry environment in our
business..

Best,

Nick
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

You know the problem with groups like this.?

If you read it in isolation, you only find out about all the problems people
are having with Multivalue products. Particularly may of the challenges
involved in interfacing applications with the outside world - particuarly
the graphical world.

It's nice though that in recent threads, people have come forward asking the
question "Whats wrong with multi-value?" "Whats wrong with a character
interface". Personally, whilst the big technical struggle for me at the
moment is providing a gui, I don't actually believe that it will improve my
application for the end users (rather the opposite for most people).

Our application (which is 99.9% character based) is probably one of the most
feature-rich in the industry. Probably has one of the lowest total cost of
ownership compared with competitors with anywhere near the feature set.

We've decided that we will continue long-term with both a character and
graphical interface. Where we gui'ze a part of our application it is only
done if the gui version provides extra features that the character version
can't. I also try to ensure that the data entry screens we have gui'ized
can be used without a mouse whereever possible. I'm amazed at how
difficult that is to write sometimes!!!

Anyways, personally I still maintain that MV still has it's place in the
world - whether as a back-end database for a windows/web application or for
producing superb character applications. It just needs some tweaking to
make the former just that little bit easier!

Just one more 2 Euro installment early on a Saturday morning!

Regards
Simon
"Nick" <nquinnusa (AT) earthlink (DOT) net> wrote

Simon, found your website, both of them! Nice roadster! DMS Sounds like a
great app.

I've been in the trade since before you were born, 33 years with IBM, NCR,
then PICK now with a very expensive back-office system for the reinsurance
business for over 20 years.

I've maintained since the advent of the 'first' gui that worked and
therefore 'required' the mouse, AND let the users do anything they wanted
to, so-called 'event' stuff, that not only is it ineffiecient, it is
expensive to maintain and even more prone to users able to put erroneous
info into the database.

I gave my users lookups, using Wintegrate, a great UK product built by David
Robertshaw and now sold by IBM, that allowed them to pick and choose codes,
a DDE download system that allowed them to extract data to disk for picking
up by Excel based upon subroutines from Wintegrate, and an MS-SQL
Datawarehouse that 'un-normalized' my database to allow them to use Crystal
and Excel to generate their own reports. That has satisfied "All of the
Users" but, of course, the DP staff has nothing to do except enhance their
resumes so "Where is GUI" is asked every year at audit time. I just remind
them that adding a hand movement to data entry is ineffiecient from an
Industrial Engineering review and that they will alienate their user
community. Users only have to get to 5PM on Friday, the harder we make it
for them to complete the work, the angier they get at not being able to
complete it, at US!

I was tested against a competitor's product once before a final sale to a
Billion USD Reinsurance company in Bermuda.

My Competitor had this all singing, all dancing Java based system over
AS-400 SQL. Our applications are similatr, it takes 6 pages of information
to completly fill out a reinsurance contract on-line.

His time: 22 Minutes per contract average for five contracts, 110 Minutes

My Time 4 Minutes average for the same 5 contracts, 20 Minutes, 75% less
user time!

You can still sell with "no mousie" if you logically present it to them. I o
nce built a simple single screen demo of the most complex 'basic details' of
my application to demonstrate this. It works to defeat GUI when they see the
drop downs mouse point etc, sub forms for associated MV's etc. etc.

We also tried to maintain two systems once, a couple of Million later we
dropped the idea.

Nice talking to you in this forum, if you'd like to know how I did SQL, just
drop me an email. It was pretty simple once we got SQL-2000.

Nick


"Simon Verona" <news (AT) aphroditeuk (DOT) com> wrote

I agree that for rapid data entry and easy to use no frills the
"green-screen" is still the way to go. I am looking at GUI for one reason
only, licensing. I get tired of having to purchase more and more licenses
for my database just so people can have more than one session open at times.
With the GUI it is easier to manipulate a single session to access the
database but allow many views into it at one time (multiple windows, data
entry screens, etc). If it weren't for the need to have all of the salesmen
in 2 order entry screens at once (entering faxed in orders and then taking a
call and returning to the fax order after the call is finished) I wouldn't
even consider it. My screens work great and are consistent and already
mostly debugged. Going GUI means starting back to square one with debugging
my system. But it is a necessary evil these days.

Marshall

"Simon Verona" <news (AT) aphroditeuk (DOT) com> wrote

Marshall,

We do it all the time, get rid of all COMMON and it is pretty simple. We
have an application with 575 screens in it and NO COMMON, all calls use a
passed named variable list. When I took over the application 15 years ago it
was full of COMMON using a Data Entry subroutine for all field entries. By
getting rid of it I just had to look for a Function key, i.e. F10, and call
the other screen to do it's work, coming back to the screen being worked on
all of the variables are still a-ok....

I processed all of the calls in a 35MB source code library over a weekend,
changing all the COM to DIM and then calling the subroutines with the
list... I even took the opportunity to pass an OPTIONS variable at the end
of the list that I did not use then. Over the years I have OFTEN used
OPTIONS to add features to the subroutines without having to touch any other
programs that use them other than the one I was working with....

Good luck, GUI has never been too successful with PICK that I have seen
unless you give up associated MV and dynamic arrays. Mice as well rewrite to
SQL, then try describing a three dimensional world in two dimensions.

Nick
"Marshall" <mlucas67 (AT) cox (DOT) net> wrote