Locked pages on edit 
Author Message
 Locked pages on edit

Hi,

I'm developing systems with SQLWindows (a Gupta development
environment for Windows) against Sybase System 10.  I generally
follow the following philosophy:  If I have a table of say,
people, I open a table on the screen that browses all the rows
in said table.  i.e. I select col1, col2, col3 from mytable into
localvars_list.  SQLWindows then retrieves all the rows into a
result set held locally on the PC.  This method has put me in a
corner as large tables (as little as 1000 rows) take a long time
to be transfered to the PC and I always end up with page locks on
said table when I want to update one of the displayed rows.

What is the general practice out in the real world when it comes
to such a schenario?  I considered starting out with a table on
screen containing all names starting with 'A%'.  The user must
enter a filter with which to populate the table on screen when
s/he wants to see another portion on the Sybase table.  This is
rather combersome.

Any other ideas??

Thanks,
Stefan Mahs,
Sanlam
(South Africa)



Fri, 10 Jul 1998 03:00:00 GMT
 Locked pages on edit

Quote:

> Hi,

> I'm developing systems with SQLWindows (a Gupta development
> environment for Windows) against Sybase System 10.  I generally...
> What is the general practice out in the real world when it comes
> to such a schenario?  I considered starting out with a table on
> screen containing all names starting with 'A%'.  The user must
> enter a filter with which to populate the table on screen when
> s/he wants to see another portion on the Sybase table.  This is
> rather combersome.

> Any other ideas??

How about only retreiving as many as you can display?  Keep a variable
that keep track of the last user displayed.  Then execute another select
when the user goes to the next page.

aka - psuedo code

declare buff_name
set rowcount 24 /*bogus filter*/

select blah from table where name >= buff_name

/*  somehow get last one  do it in app or here ??  */
select max(name) from table where name >= buff_name

When the user wants to see the next page, call the proc for next result
set.

You'll have to work out the details, but it might do in a pinch.

Don't use scroll bars, use a drop down list or grid.  On second thought
you can use scroll bars, but it looks like more of a pain to me.

Incidently, never, ever lock the table until a user does something -
that's the impression I got from your post.  Rather, use a timestamp to
see if values changed before doing an update - but that's another story.

JB



Sun, 12 Jul 1998 03:00:00 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. Q: Padding pages and page locking

2. Page lock to simulate row level lock

3. page lock or table lock

4. ORACLE record locking acting like page locking

5. Row locking versus page locking

6. SYBASE page locks outperform ORACLE row locks

7. Row-locking instead of page-locking ?

8. Paradox 5.0: Row level locking or page locking?

9. Print Rich Edit from a Database in several pages

10. page editing in sybase NT


 
Powered by phpBB® Forum Software