[comp.databases] some questions on DBASE III +

pew@cs.brown.edu (Peter E. Wagner) (03/13/91)

In article <20990@shlump.nac.dec.com>, yychow@pasm07.enet.dec.com (yychow) writes:
|> Hi Everyone, 
|> 
|> 	I need a number of questions for you, if you know the answer
|> 	on one or more questions listed below, please write here or
|> 	directly sent mail to the address below.
|> 
|> 	All below cases are to be assumed in a network environment.
|> 
|> 	1) If I have two applications say prog1 and prog2, and want to
|> 	   have a main menu (main) to call up either one of them. Do I 
|> 	   need to re-organize all the select area when multiple users 
|> 	   is using the programs????
|> 
|> 	                  -----	main------
|> 			  |              |
|> 			  |              |
|> 			prog1		prog2
|> 			-----		-----
|> 			select 1 	select 1
|> 			use test1	use test2
|> 
|> 	   If not so, I shall assume that multiple users will not affect
|> 	   each other..
|> 

Users will not affect each other in this case.  Each user can have
their own set of open files in any work areas they choose.  User 1 can
have test1 open in select area 1 and test2 in select area 2, while
user 2 has test1 open in select area 2 and test2 open in select area
1.  Of course, you do have to worry about file and record locking
preventing the users from doing what they want.

|> 	2) For a large application, it is difficult to open all the files
|> 	   in a different selected areas once.. So if I write for each function
|> 	   to open the the corresponding required database files and close 
|> 	   them when I finished using them. In a single user-environment, 
|> 	   there will not be any problem, but about when it is in 
|> 	   a multiple users environment, will this approch affect the 
|> 	   users using the system? 
|> 
|> 	   Say I have two users (user1 & user2)and they are working on with 
|> 	   the same application but different functions, will the user1 
|> 	   affect the user2.
|> 
|> 			user1		user2
|> 			-----		-----
|> 			function1      function2
|> 			   |		  |
|> 
|> 			select 1 	select 1
|> 			use test1	use test2
|> 
|> 	    Will the user1 be working on test1, and user2 be working test2
|> 	    without affecting each other???
|> 

I think this is the same question as your first, and the same answer
applies.  If I have misinterpreted you, please let me know and I will
try to answer.


|> 	3) I believe many of you have used clipper to compile your application.
|> 	   From the reference manual, it mentions ones could open up to
|> 	   256 areas, i.e., select 1 to select 256... But I have an application
|> 	   which only open ten database files and 10 indexed files. whenever 
|> 	   it reach to the area 9, it gives me an error message like "error
|> 	   on open indexed file name_of_file", I have checked the indexed 
|> 	   file, and re-create the indexed file, it still does not work. 
|> 	   Can someone tell me what is wrong with it? By the way, I have set
|> 	   the following:
|> 
|> 		config.sys
|> 		==========
|> 		files = 50
|> 
|> 		autoexec.bat
|> 		============
|> 		set clipper = F50
|> 
|> 	   This should enable me to open up to 50 files, right !!!

I do not know Clipper, though I hear that it is excellent.  Even so, I
would strongly recommend that you look at Foxbase instead of dBase
III+.  It is much, much, much, MUCH faster and more reliable than
dBase III+ while being 100% compatible.  You will not have to rewrite
any code or relearn anything, though there are a few extra features
that are really nice like save and restore screen.  If you want to
jump to an even more advanced environment, you can migrate to FoxPro.
FoxPro will run your dBase application while being even faster than
Foxbase.  It also has a zillion more features.  However, it is
different enough from dBase that there is a bit of a learning curve.
Of course this learning curve is due to the fact that you want to
program differently with all of the new advanced features.  You can
continue to program exactly as you would in dBaase III+, but you would
not be taking advantage of the environment.  You can probably get
Foxbase for about $100 while FoxPro runs about $400+.  I always
recommend these products to people who are using dBase, since I feel
that it is the best move I ever made.  Good luck!

    Peter

yychow@pasm07.enet.dec.com (yychow) (03/13/91)

Hi Everyone, 

	I need a number of questions for you, if you know the answer
	on one or more questions listed below, please write here or
	directly sent mail to the address below.

	All below cases are to be assumed in a network environment.

	1) If I have two applications say prog1 and prog2, and want to
	   have a main menu (main) to call up either one of them. Do I 
	   need to re-organize all the select area when multiple users 
	   is using the programs????

	                  -----	main------
			  |              |
			  |              |
			prog1		prog2
			-----		-----
			select 1 	select 1
			use test1	use test2

	   If not so, I shall assume that multiple users will not affect
	   each other..

	2) For a large application, it is difficult to open all the files
	   in a different selected areas once.. So if I write for each function
	   to open the the corresponding required database files and close 
	   them when I finished using them. In a single user-environment, 
	   there will not be any problem, but about when it is in 
	   a multiple users environment, will this approch affect the 
	   users using the system? 

	   Say I have two users (user1 & user2)and they are working on with 
	   the same application but different functions, will the user1 
	   affect the user2.

			user1		user2
			-----		-----
			function1      function2
			   |		  |

			select 1 	select 1
			use test1	use test2

	    Will the user1 be working on test1, and user2 be working test2
	    without affecting each other???

	3) I believe many of you have used clipper to compile your application.
	   From the reference manual, it mentions ones could open up to
	   256 areas, i.e., select 1 to select 256... But I have an application
	   which only open ten database files and 10 indexed files. whenever 
	   it reach to the area 9, it gives me an error message like "error
	   on open indexed file name_of_file", I have checked the indexed 
	   file, and re-create the indexed file, it still does not work. 
	   Can someone tell me what is wrong with it? By the way, I have set
	   the following:

		config.sys
		==========
		files = 50

		autoexec.bat
		============
		set clipper = F50

	   This should enable me to open up to 50 files, right !!!


	Thanks in advance...
			    YY.

	   
---                                                                   
 Y. Y. Chow	yychow@pasm07.enet.dec.com                       
 		---or---   ...!decwrl!pasm07.enet!yychow         
 		---or---   yychow%pasm07.enet@decwrl.dec.com     
---                                                                      

timk@wynnds.xenitec.on.ca (Tim Kuehn) (03/13/91)

In article <68237@brunix.UUCP> pew@cs.brown.edu (Peter E. Wagner) writes:
>In article <20990@shlump.nac.dec.com>, yychow@pasm07.enet.dec.com (yychow) writes:

>|> 		config.sys
>|> 		==========
>|> 		files = 50
>|> 
>|> 		autoexec.bat
>|> 		============
>|> 		set clipper = F50
>|> 
>|> 	   This should enable me to open up to 50 files, right !!!

I don't think so. If I remeber my DOS batch commands right, those 
spaces are what's causing you problems. do a "set" command all by 
itself and see what the clipper env. var is set to. If it's not 50, 
then do: 

set clipper=f50

_exactly_ as it's written above. 

I've been bitten by this one more than once. 

   ------------------------------------------------------------------------ 
   Tim Kuehn			    TDK Consulting Services  (519)-888-0766
   timk@wynnds.xenitec.on.ca  -or-  !{watmath|lsuc}!xenitec!wynnds!timk
   Valpo EE turned loose on unsuspecting world! News at 11!

tleylan@pegasus.com (Tom Leylan) (03/13/91)

In article <20990@shlump.nac.dec.com> yychow@pasm07.enet.dec.com (yychow) writes:
>	All below cases are to be assumed in a network environment.
>
>	1) If I have two applications say prog1 and prog2, and want to
>	   have a main menu (main) to call up either one of them. Do I 
>	   need to re-organize all the select area when multiple users 
>	   is using the programs????
>
>	                  -----	main------
>			  |              |
>			  |              |
>			prog1		prog2
>			-----		-----
>			select 1 	select 1
>			use test1	use test2
>
>	   If not so, I shall assume that multiple users will not affect
>	   each other..

Right off the bat you should avoid expressly using any particular workarea
and simply use the SELECT 0 construct.  This will open the file in the next
available workarea.  You should refer to workareas by their alias names
after you have opened a file there.

As for your example as long as you close the files in the same programs that
you open them in no problems will develop.  Keep in mind that each user
executes their own copy of the .EXE file so the only network conflicts
can result from rights to the data files.
>
>	2) For a large application, it is difficult to open all the files
>	   in a different selected areas once.. So if I write for each function
>	   to open the the corresponding required database files and close 
>	   them when I finished using them. In a single user-environment, 
>	   there will not be any problem, but about when it is in 
>	   a multiple users environment, will this approch affect the 
>	   users using the system? 
>
>	   Say I have two users (user1 & user2)and they are working on with 
>	   the same application but different functions, will the user1 
>	   affect the user2.
>
>			user1		user2
>			-----		-----
>			function1      function2
>			   |		  |
>
>			select 1 	select 1
>			use test1	use test2
>
>	    Will the user1 be working on test1, and user2 be working test2
>	    without affecting each other???

Similarly to answer one... the network doesn't actually know or care what one
workstation is running while somebody uses another workstation.  The programs
are loaded in RAM.  If problems develop (and they can) it would be because
one person has exclusive use of a file that another use wants or has a file
or record lock in place.  In the worst case a deadlock can occur when both
apps sit around forever waiting for the other app to give release the
file lock.  There are obvious ways to prevent this and you should try and
find a book on network programming.
>
>	3) I believe many of you have used clipper to compile your application.
>	   From the reference manual, it mentions ones could open up to
>	   256 areas, i.e., select 1 to select 256... But I have an application
>	   which only open ten database files and 10 indexed files. whenever 
>	   it reach to the area 9, it gives me an error message like "error
>	   on open indexed file name_of_file", I have checked the indexed 
>	   file, and re-create the indexed file, it still does not work. 
>	   Can someone tell me what is wrong with it? By the way, I have set
>	   the following:
>
>		config.sys
>		==========
>		files = 50
>
>		autoexec.bat
>		============
>		set clipper = F50
>
>	   This should enable me to open up to 50 files, right !!!
>
I believe you will find that there is a 255 workarea limit but that only
works with DOS 3.3 (or I suppose 4.nn also).  Remember that DOS itself
uses five handles so I think your example would permit 45 files opened.

File handles are used for more than .DBF files, each .NTX requires one and
if there are overlay files they require one and .MEM files (if you use them
which you shouldn't) and other things use them also.  Most importantly
if you are on a network, the network may not permit one application to have
255 handles to itself so check your network manual.  3COM is particularly
stingy in this regard.

Hope this helps

tom leylan
ex-Senior Systems Analyst - Nantucket Corporation

sean@apexepa.UUCP (Sean Donovan) (03/13/91)

In article <20990@shlump.nac.dec.com> yychow@pasm07.enet.dec.com (yychow) writes:
>Hi Everyone, 
>[...] {Two questions about the affect of dbase apps running on networks.}

When you run a dbase program on a machine connected to a network, say 
from the network server, you host machine loads its own copy of dbase
and the application into its memory. This means that each machine on the
network which is running the program has its own set of work areas, file
handles, etc. These are private to the machine running the application, so
another node running the same application cannot interfere with the
operations such as select, etc.

The only thing that you must keep in mind when writing network applications
is: how and when are your .dbf files accessed. You must be aware that some
commands and functions place file and record locks on the data, which means
that your users may not be able to access it all the time. You must be aware
that the data contained within the .dbf files may have occasion to change
right under one nodes nose. In general, you have to pay specific attention
to how your application accesses and manipulates the data stored in files
shared by the application.

>[...]{Clipper question}

Sorry can't help you there, I've never run it.


Hope this helps,


Sean Donovan  uunet!apexepa!sean

pew@cs.brown.edu (Peter E. Wagner) (03/14/91)

In article <1991Mar13.101820.4102@pegasus.com>, tleylan@pegasus.com (Tom Leylan) writes:
|> In article <20990@shlump.nac.dec.com> yychow@pasm07.enet.dec.com (yychow) writes:
|> 
|> Right off the bat you should avoid expressly using any particular workarea
|> and simply use the SELECT 0 construct.  This will open the file in the next
|> available workarea.  You should refer to workareas by their alias names
|> after you have opened a file there.

I don't think that dBase III+ supports SELECT 0.  It's been a while,
though.

    Peter

thayne@unislc.uucp (Thayne Forbes) (03/16/91)

From article <68396@brunix.UUCP>, by pew@cs.brown.edu (Peter E. Wagner):
> In article <1991Mar13.101820.4102@pegasus.com>, tleylan@pegasus.com (Tom Leylan) writes:
> |> In article <20990@shlump.nac.dec.com> yychow@pasm07.enet.dec.com (yychow) writes:
> |> 
> |> Right off the bat you should avoid expressly using any particular workarea
> |> and simply use the SELECT 0 construct.  This will open the file in the next
> |> available workarea.  You should refer to workareas by their alias names
> |> after you have opened a file there.
> 
> I don't think that dBase III+ supports SELECT 0.  It's been a while,
> though.
> 
What he said.  I had the same problem when I had to port to an old version
of Foxbase the was stricly compatible. I wrote a procedure called
SELECT0 that did the same thing.  I don't remember it all now but I did
a while loop, counting from 1 to 10, and did a dbf() for each area to
see if a file was open.  It would return on the first empty area.

Now does anyone remember if dBase had the dbf() function?
-- 

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# The opinions expressed above are my wife's, but she said I could use them. 

awd@dbase.A-T.COM (Alastair Dallas) (03/29/91)

In article <1991Mar15.162050.16222@unislc.uucp>, thayne@unislc.uucp (Thayne Forbes) writes:
> Now does anyone remember if dBase had the dbf() function?

dBASE III PLUS _invented_ the dbf() function.

/alastair/


-- 
|Disclaimer: I am speaking for myself, not as a spokesman for Ashton-Tate,
|which does not monitor my outbursts here.  I reserve all rights to my
|opinions in terms of commercial endorsements.