Re: One File To Capture All Transactions

Hi
I am thinking particularly of the internet situation where there may well be significant delays between disparate systems that could cause the transactions to not wind up in the correct order. Also one might wind up tripping over the systems memory checks and flushing.
As you say the old "lock or not lock" debate can be quite interesting particularly when people are doing bookings from the other side of the world. I booked a UK trip in bits and pieces mostly successfully. However the current US paranoia means that it is probably best not to book anything but a travel agent round trip if you don't want to be stripped by goons at every airport.

Credit cards are always interesting when dealing with large purchases. I was surprised to get a call in Hong Kong because I had bought goods in Melbourne and HK on the way through to UK. They were on to the change in pattern within 24 hours so it pays to keep checking your home phone recordings. However conducting conversations about credit card problems from afar with shops where the main language is not one's native language can be testing :-)

The problem of locking out an order because of stock availability is a significant issue and I feel that it is more likely to be affected by the people on the floor than the system so it is probably not worth the trouble in many instances. I would not be the only one who has been sent back to get a credit because the counter system said there was one there and the storeman said there wasn't. Equally frustrating is the situation of having the item in hand and the system refusing it. People get very creative in these circumstances. A couple of months ago I bought "parts for Dannys mower" because the system was determined that the Gerni drain rat that I had in my hand was $130 and not the correct figure of $75 that was on the ticket. That should screw the system well and truly.

I have had arguments with several accountants over the years because my oil system will allow stock to go negative or allow orders to be taken when there is no stock on hand. They do not seem to be able to grasp that a chap will pick up the invoices from a remote location, then got to an oil installation and load up to do the deliveries. Better still he does not know how much he will deliver until he gets there and dips the tank, so he may run out half way round and goto to another installation to fill up again. I did have one delivery round that covered 5 states and territories over 3-4 weeks and he would top up at Broken Hill NSW on the way back to South Australia having been to Western Australia, Northern Territory and Queensland all for one customer with different state taxes and prices. What really floored the accountant was that if he had light orders he would drop off the third tanker trailer and replace it with a flat loaded with beer as he knew he would sell that.

Of course if you really want to argue with an accountant then FIFI, LIFO etc will really get them going and this transaction thing gets interesting. Where do you pick up the cost, as you enter the order or as you post the update? We actually use replacement cost for bulk fuel product which flips some of them clean out of their tree. I do allow myself a wry smile as I think of the hours nay weeks that we spent at university on the topic of current cost accounting back in 1970 and a particular beauty "depreciation cash flows".

Peter McMurray



"Kevin Powick" <kpowick@xxxxxxxxx> wrote in message news:e9e79e89-897f-4873-bb5a-54ce7d461e64@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Feb 24, 7:07 pm, "Peter McMurray" <excalibu...@xxxxxxxxxxx> wrote:

An Interesting idea. The opposite of a system transaction log. However I
am afraid that it is quite undoable because every read from anywhere would
need to check your update file to see if the item it was about to read was
in the queue somewhere then wait for the update. I can see some spectacular
clashes with items such as stock updates or airline/concert ticketing
queues.

May or may not be true depending on your approach to the system.

If optimistic locking, that item in the queue is considered an
unprocessed request, which is no different than a user looking at
their screen, waiting to press <return> on some transaction.

What you say *would* apply if you desired the guarantee of a
pessimistic locking scheme that ensures that the qty on an order
screen remains locked and valid until you commit or abandon the order.

There have been many debates here about locking schemes, so I'll pass
if anyone feels the need to beat that poor horsey again.

Up until now I have always used pessimistic (oops
sorry Chandru ) proper locking however internet stateless situations have
made me reconsider and I shall make a minor change to the audit read to
incorporate the lock immediately prior to the update.

Yes, unknown state and scalability issues require a rethink of the
"proper" locking approach.

The shopkeeper puts a hold on the initial $4000 while the deal proceeds
unfortunately when the final price comes to say $4927 they put a new charge
through and forget to release the initial $4000. It getes even better when
the receiving bank software stuffs up the transaction reversal :-)

I remember having my Visa card declined at a hotel several countries
away from home due to it being over the limit. I found that quite
unbelievable since I only use the card for travel expenses, always pay
off the balance upon my return, and had done just so prior to this
particular trip.

It seems back then (90's) that Visa's international computer system
didn't update, in real time, all the locations from where a balance
inquiry might be made. Anyway, this is what I gathered during my
rather heated conversation with the "Visa person" on the other end of
the phone while standing at the hotel's front desk. Despite my best
efforts and charming personality that you all have come to know and
love, Visa wasn't going to budge on this. Fortunately, the kind
(scared?) clerk at the front desk allowed it to slide until the
morning, when of course he would be off and someone else could deal
with it.

In the morning a call to the right customer service dept got it all
straightened away, but it did serve to teach me to have at least
enough local currency on hand for a night or two just in case credit
cards fail.

--
Kevin Powick

.

Relevant Pages

  • Re: Working Transactions somehow started not to work
    ... Transaction and locking are not properties of recordsets but are properties ... Opening a served-based cursor will put a lock on ... SL> and are not associated necessarily with server-based cursors. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Help - Timing Logic
    ... If you need to implement a locking mechanism / or / logging mechanism / or / a checking mechanism to avoid duplicate messages caused by multi-threading ... ... Is it the READ from the database ... ... Perhaps a stored proc may be faster to execute and return the values as opposed to building the transaction in the code. ... implement as above locking only the records you retrieve / update - need to watch out here for table locking ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: MATREADU/MATWRITE statements timing out
    ... Locking of transaction records (as ... If I take a typical debtor master file I can be ... Pessimistic locks for transactions (required for transaction ...
    (comp.databases.pick)
  • Re: Help - Timing Logic
    ... put a trigger on the database table. ... Transaction and Database Locking - look at isolation levels / settings ... Maybe implement a message broker ... ...
    (microsoft.public.dotnet.languages.vb)
  • Xlocking with a select statement
    ... SQL Server does not honour exclusive row level locking ... set transaction isolation level repeatable read ... This correctly blocks window two as expected. ... Sql server has taken out locks ...
    (microsoft.public.sqlserver.programming)
Loading