Re: Unpack When?
- From: "Peter McMurray" <excalibur21@xxxxxxxxxxx>
- Date: Fri, 21 Nov 2008 05:54:54 GMT
Hi
I must admit that normal locking is my preferred way - I always supply an
enquiry screen that does not lock a record as well as the update screen and
I never include a deletion screen for a master record once the system has
been fired up although I have seen some horrors in that area.
The idea of passing a quick couple of hundred records down is to make a
selection of the one you are after eg Products or Delivery Addresses.
The stateless thing is exercising my mind somewhat heavily. As you and
others have pointed out it depends what one is doing. Unfortunately there
are plenty of smart-alecs out there who deride a system simply because it is
terminal based whereas spinning whizgigs that add nothing to the package
excite them. I am considering keeping both terminal and browser options
open within my code. Amrk demonstrated an excellent combination of Pick and
Dos photographs many years ago that excited law enforcement agancies and
upset felons. Ints Tumilovics did some great things with Briz and court
documents. So there are reasons.
Peter McMurray
<cmurthi@xxxxxxxxxxxxxxx> wrote in message
news:804ee314-15d5-4ed6-ad81-ac582200ea7b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Nov 19, 7:03 pm, "Peter McMurray" <excalibu...@xxxxxxxxxxx> wrote:
I am revamping my entire suite with a view to a browser interface. There
are the obvious issues such as optimistic locking and a lack of state,
but
No... have you been following the numerous other threads on these
issues? You can do normal (I hate "pessimistic") locking as God and
Pick intended us to do and not piss off your users with optimistic
lock error messages. And state's just as easy to maintain, I would not
design anything stateless.
another major point is when to unpack a Pick item. Dawn raised this in a
way a couple of weeks ago with a query about the Pick date that she
subsequently solved within a Cache MV function that I presume is executed
on
the server. However she is using the Rolls Royce solution of Cache ZEN
whereas I am considering a simpler cross platform solution.
Is it better to just shoot a Pick item down the line and unpack it at the
user interface or is it better to do all the work in Pick on the server
and
just send the selected result that will need repacking upon return? When
one
considers the power available at the user end these days and the fact
that
the server is flying around like a one-armed paper-hanger catching and
servicing requests from everywhere it seems that a considerable amount
can
be done at the user end. In fact it seems to me that mv.Net does a great
deal at the user end.
Generally speaking, the best way would be to convert Pick-style data
(which are really only dates, numbers) to "display" format on the
server before sending over. It's only an OCONV[S] out, and the ICONV
[S] on the receipt. This makes validation of user-entered data easier,
but of course makes any kind of math or comparison horrendous (for
dates). You takes your choice.
Obviously I am referring to items such as a debtor master or an invoice
not
a list of possible name selections. I think that it was Mark Brown that
suggested bunging a couple of hundred results from a btree into a message
and sending them was a good way around the latter item, and I
wholeheartedly
agree.
Don't remember this...is it a way to validate data entry against a
portion of the file?
Chandru
Peter McMurray
.
- Follow-Ups:
- Re: Unpack When?
- From: Anthony . Youngman
- Re: Unpack When?
- References:
- Unpack When?
- From: Peter McMurray
- Re: Unpack When?
- From: cmurthi
- Unpack When?
- Prev by Date: Re: Unpack When?
- Next by Date: Re: D3 ODBC from vmware xp?
- Previous by thread: Re: Unpack When?
- Next by thread: Re: Unpack When?
- Index(es):
Relevant Pages
|
