[AccessD] Desperately Seeking!

MartyConnelly martyconnelly at shaw.ca
Sat May 3 13:06:19 CDT 2003


There are several adjacency alogrithms used in GIS or graphics systems, 
that allow color merging
of  pixels. Don't remember the name of class. But essentially it as 3 
dimensional matrix (x,y,color)
and you just search for where red and blue touch and change color to 
purple. You only have 8 pixels touching each other, unless on a 
boundary. There are other methods for vectors where you have a centroid 
to the left or right of line and a color associated with the centroid..

Arthur Fuller wrote:

>To be sure, there are apps such as those you describe, where sales reps are
>contending for tickets or seats or whatever. The way I handled it in the
>concert app was this: every physical ticket was one row in a table, complete
>with a gate, row and seat ID. To simplify the data-entry I wrote a form that
>would let someone create blocks of tickets very quickly (i.e. gate 7, row 1,
>seats 1-50, &c.) This was necessary because the sales people would have to
>assign contiguous tickets where possible, and I never could come up with an
>algorithm that would understand the asssignment contingencies the way peple
>do intuitively. For example, if you don't have 4 adjacent seats but you do
>have two pairs -- seats 1 and 2 in rows 7 and 8 -- that will do. After that
>was done, a multi-select listbox was all the front end required (plus a
>timer that released the locks after 5 minutes unless the sale was
>completed).
>
>Anyway, your point is valid. That's why I went to the seat=row model. There
>was no other way that I could see to avoid contention. Even then there was
>still a possibility, so we locked the rows the moment they were selected.
>And we didn't have thousands of users selecting seats :-)
>
>A.
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Henry Simpson
>Sent: May 3, 2003 3:13 AM
>To: accessd at databaseadvisors.com
>Subject: RE: [AccessD] Desperately Seeking!
>
>
>Arthur:
>
>You did some concert booking at come point.  How did you manage concurrent 
>attempts to reserve the same seats (records?) in a hall, for transportation 
>and hotel rooms.  There are concerts where 20 - 30,000 seats are booked in a
>
>matter of hours and some kind of software layer that feeds non overlapping 
>blocks of seats to a number of terminals must be provided by software so 
>each booking terminal could present a range of seat selections.  It seems to
>
>me that block allocation of the declining available records is an aspect of 
>workflow that is the responsibility of the application developer.  In an 
>airline scenario, where you have thousands of agents who might be 
>simultaneously contending for a small block of seats, is there a trivial 
>work flow solution?
>
>I would think that the only other way to work disconnected is verify that 
>all the record fields contain the same data at the server as at the client 
>before committing an update or to write a lock flag to a record (with a 
>date/time stamp) that is automatically cleared by some kind of bot 
>application if a reservation isn't committed within a specified time span.  
>For consistency, you could have the client pull the time from a server table
>
>(updated every few seconds?) and have the bot clear any stamps that are 
>future times.
>
>Hen
>
>
>
>
>  
>
>>From: "Arthur Fuller" <artful at rogers.com>
>>Reply-To: accessd at databaseadvisors.com
>>To: <accessd at databaseadvisors.com>
>>Subject: RE: [AccessD] Desperately Seeking!
>>Date: Fri, 2 May 2003 14:26:42 -0400
>>
>><rant>
>>I don't feel like rekindling any bound/unbound wars, so instead I'll 
>>try another tack. The problem is disconnected recordsets, which are 
>>very cool if the liklihood of simultaneous updates of a row is remote. 
>>In fact, it's not so much a database problem as a business practices 
>>problem, IMO. What the hell are two people updating the same row for? 
>>There's a problem here and it
>>doesn't concern the database; it concerns the workflow, which by definition
>>is outside the specifications. OTOH, excellent arguments from the db folk
>>occasionally persuade management that the problem is indeed outside the db,
>>and should be addressed by someone other than you.
>></rant>
>>
>><reality>
>>Given that you must prevent simultaneous updates of a set of rows, and
>>given
>>that you have taken the unbound path, without a massive rewrite I think 
>>your
>>quickest option is to revisit all the recordset declarations, setting
>>Pessimism TRUE in your rs.open() arguments. This effectively offloads the
>>problem to the db, which is good, since it won't allow your users to
>>overwrite each other even if your app in theory does. (That's why I always
>>put all the smarts into sprocs and rules and such, rather than coding them
>>in Access. Then, even if your app is buggy, it doesn't matter:-) Lock it 
>>all
>>down with pessimistic recordsets and go from there. You can probably visit
>>every occurenece with a project-wide search, and paste the revised string
>>in.
>></reality>
>>
>><fantasy>
>>I'm having difficulty coming up with an example where multiple users 
>>would want to update the same rows. A wife and husband are both phoning 
>>to complain about a VISA charge? Three employees are calling from 
>>Client X to revise the purchase quantities in the details of OrderID 
>>2345?
>>
>>Multiple people updating identical rows = a workflow problem, IMO. In a 
>>well-designed workflow, this should never occur.
>>
>>Making this point at your next meeting, you are given a 100% salary 
>>boost, several opportunities for sex with strangers, and the pleasure 
>>of watching the entire organization reconfigure itself to your 
>>insights. Suddenly they appreciate how brilliant you are and shape 
>>their enterprise around you. Billions at stake, all on your mind. 
>></fantasy>
>>
>>Arthur
>>
>>-----Original Message-----
>>From: accessd-bounces at databaseadvisors.com
>>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Marcus 
>>Tewksbury
>>Sent: May 2, 2003 10:16 AM
>>To: accessd at databaseadvisors.com
>>Subject: [AccessD] Desperately Seeking!
>>
>>
>>Can Anyone Help Me?
>>
>>I have built a client server application using .adp front end and SQL
>>Server
>>back end.  Within the application itself I use unbound forms and retrieve
>>records using ADO recordsets at run time.  The way I have initially 
>>deployed
>>the application is to copy an instance of the .adp to each desktop and run
>>it locally.  The problem has been that people keep overwriting each other's
>>updates - and changes are not reflected fast enough.
>>
>>I have a couple of different thoughts on how to tackle this - either
>>ratchet
>>down the ODBC refresh rate, or run a single, centralized copy of the .adp
>>(which throws up some non-updateable warning every time it starts which I
>>don't know how to suppress).  Of course, I acknowledge that I am a total
>>newbie, and both of these options may be flawed.
>>
>>Thanks a bunch,
>>
>>- Sherri
>>    
>>
>
>
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*   
>http://join.msn.com/?page=features/junkmail
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>  
>




More information about the AccessD mailing list