judge@gpu.utcs.utoronto.ca (Peter Judge) (11/23/90)
Hi, I am a Mac literate person who knows only a little about networking or databases. I need to network three to five macs running a 4th Dimension application. Three machines are located in separate regions so I would have to connect them via telephone lines; the others would be connected by cable. My questions are these: 1) How does 4th Dimension make use of modems to share a distributed database? Does it contain routines to implement networking over phone lines, or do I need a bridge? (Technical information regarding the purchase, installation and use of bridges would be welcome). 2) Is there recommended networking software to use with 4th Dimension (Appletalk, TOPS...)? Thank you in advance for your help. Please respond via e-mail since I don't read this newsgroup very often. ========================== Peter Judge judge@credit.erin.utoronto.ca -- =============================================== judge@credit.erin.utoronto.ca (Peter Judge) |) judge@gpu.utcs.utoronto.ca ===============================================
bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) (11/23/90)
In article <1990Nov23.000340.1514@gpu.utcs.utoronto.ca> judge@gpu.utcs.utoronto.ca (Peter Judge) writes: > >I need to network three to five macs running a >4th Dimension application. Three machines are >located in separate regions so I would have to >connect them via telephone lines; the others would >be connected by cable. > >My questions are these: > >1) How does 4th Dimension make use of modems to > share a distributed database? It doesn't. > Does it contain routines to implement networking > over phone lines, or do I need a bridge? You would need a bridge. >2) Is there recommended networking software > to use with 4th Dimension (Appletalk, TOPS...)? Data corruption problems have occurred with TOPS. Bad idea. 4D uses a file server rather than a client/server model, so phone line networking is next to impossible with 4D. The closest you could come is to mimic a distributed database design, with batch updating between central database and remote databases at periodic intervals. A more expensive approach is to use 4D as a front end to an Oracle database, which should support the distributed databases. Alternatively, you could run "headless" macs at your central site, each with timbuktu/remote or carbon copy mac running, and access these macs via v.42bis modems from your remote sites. That may be a reasonable implementation, since you transfer screen images rather than data across the phone lines. You could enter and review data on-screen, but you wouldn't be able to print at a remote site using this approach. Best regards, ==== Brian K. Martin, M.D. Martin Information Systems, Ltd. 1103 9th Ave, Suite 203 Honolulu, HI 96816-2403 Voice (808) 733-2003 Fax (808) 733-2011 INTERNET: martin@medix.pegasus.com, bmartin@uhccux.uhcc.hawaii.edu ARPA: uhccux!bmartin@nosc.MIL UUCP: {uunet,dcdwest,ucbvax}!ucsd!nosc!uhccux!bmartin
boris@world.std.com (Boris Levitin) (11/25/90)
bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) writes: >In article <1990Nov23.000340.1514@gpu.utcs.utoronto.ca> judge@gpu.utcs.utoronto.ca (Peter Judge) writes: >> >>I need to network three to five macs running a >>4th Dimension application. Three machines are >>located in separate regions so I would have to >>connect them via telephone lines; the others would >>be connected by cable. >> >>My questions are these: >> >>1) How does 4th Dimension make use of modems to >> share a distributed database? > It doesn't. >> Does it contain routines to implement networking >> over phone lines, or do I need a bridge? > You would need a bridge. >>2) Is there recommended networking software >> to use with 4th Dimension (Appletalk, TOPS...)? > Data corruption problems have occurred with TOPS. >Bad idea. 4D uses a file server rather than a client/server model, so phone >line networking is next to impossible with 4D. The closest you could >come is to mimic a distributed database design, with batch updating >between central database and remote databases at periodic intervals. >A more expensive approach is to use 4D as a front end to an Oracle database, >which should support the distributed databases. >Alternatively, you could run "headless" macs at your central >site, each with timbuktu/remote or carbon copy mac running, and access >these macs via v.42bis modems from your remote sites. That may >be a reasonable implementation, since you transfer screen images rather than >data across the phone lines. You could enter and review data on-screen, but >you wouldn't be able to print at a remote site using this approach. I don't see why the original poster couldn't connect his five local AppleTalk networks using Telebridges. Of course, this will be Chinese-water-torture- slow, but it should work. For a more realistic setup, the original poster should probably go to TCP/IP over Ethernet and then connect the Ethernets. Incidentally, Tops claims that it solved the file-corruption problems in version 3.0. I don't use 4th Dimension, but had a nasty corruption problem with a distributed Excel file and Tops 2.0. Since we installed 3.0, it hasn't happened again in a year and a half.
urlichs@smurf.sub.org (Matthias Urlichs) (11/28/90)
In comp.sys.mac.comm, article <10381@uhccux.uhcc.Hawaii.Edu>, bmartin@uhccux.UUCP (Brian Martin) writes: < In article <1990Nov23.000340.1514@gpu.utcs.utoronto.ca> judge@gpu.utcs.utoronto.ca (Peter Judge) writes: < > < > Does [ 4D ] contain routines to implement networking < > over phone lines, or do I need a bridge? < You would need a bridge. < 4D does have some procedures to talk to the modem port. (They don't help in this case, however...) < >2) Is there recommended networking software < > to use with 4th Dimension (Appletalk, TOPS...)? < Data corruption problems have occurred with TOPS. In the past, this was because Tops implemented record locking in a way which is incompatible with the way Apple does it. < < A more expensive approach is to use 4D as a front end to an Oracle database, < which should support the distributed databases. < For this, 4D looks like the wrong solution. < Alternatively, you could run "headless" macs at your central < site, each with timbuktu/remote or carbon copy mac running, and access < these macs via v.42bis modems from your remote sites. That may < be a reasonable implementation, since you transfer screen images rather than < data across the phone lines. You could enter and review data on-screen, but < you wouldn't be able to print at a remote site using this approach. < Also, screen access should be significantly slower than shipping the raw data over the line. You'd also tie up one mac per remote user, which is prohibitively expensive. What I would use is a mac or two with Liaison, and/or a bridge which can be connected to a modem (NetBridge, whatever). Use this to access a file server. (AppleShare-compatible. If you wait a few more months you can use FileShare from System 7.0.) Anything below a 9600 Baud V.32 modem is not a good idea -- file server access is impossibly slow with 2400 baud. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/
bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) (12/09/90)
In article <eb3mg2.hq4@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.sys.mac.comm, article <10381@uhccux.uhcc.Hawaii.Edu>, > bmartin@uhccux.UUCP (Brian Martin) writes: >< In article <1990Nov23.000340.1514@gpu.utcs.utoronto.ca> judge@gpu.utcs.utoronto.ca (Peter Judge) writes: > >< Alternatively, you could run "headless" macs at your central >< site, each with timbuktu/remote or carbon copy mac running, and access >< these macs via v.42bis modems from your remote sites. That may >< be a reasonable implementation, since you transfer screen images rather than >< data across the phone lines. You could enter and review data on-screen, but >< you wouldn't be able to print at a remote site using this approach. >< >Also, screen access should be significantly slower than shipping the raw data >over the line. You'd also tie up one mac per remote user, which is >prohibitively expensive. Here's why it doesn't make sense to ship raw data over a line. Let's say you have a 4D database with 70,000 records in one of its files (I have one). Let's also assume that each record contains, on average, 100 bytes. Guess what happens when you want to do a simple search, such as: SEARCH([Patients];[Patient]ZipCode="96786") 4D downloads all 70,000 records (about 7,000,000 bytes) from the fileserver to your machine, and does the entire search on your machine. Guess how long it takes to download 7MB, even at 38,000 baud? Compare that to 1,000,000 baud download speed via Ethernet to a local Mac running 4D. You could optimize this by indexing the field you plan to search on. In that case, with overhead, you're still going to download 700,000 bytes (10 bytes of data & index overhead per indexed record * 70,000 records) just to do a simple indexed search. That's still a lot of overhead for phone lines. I've actually run all these tests, and we currently use timbuktu/remote with headless macs for dialup access, as it provides the _only_ reasonable performance. Although this ties up one mac per dialup line, the development and maintenance costs may be cheaper than going to a conventional client server model, where the data server would be Sybase, Ingres or Oracle. Using the Mac IILC, the cost per dialup line would probably be less than $3,500, including two v.42bis modems and two copies of Timbuktu Remote. Best regards, Brian K. Martin, M.D. 1103 9th Avenue, Suite 203 Honolulu, Hawai`i 96816-2403 Voice (808) 733-2003 Fax (808) 733-2011 INTERNET: martin@medix.pegasus.com, bmartin@uhccux.uhcc.hawaii.edu ARPA: uhccux!bmartin@nosc.MIL
time@tbomb.ice.com (Tim Endres) (12/10/90)
In article <10559@uhccux.uhcc.Hawaii.Edu>, bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) writes: > 4D downloads all 70,000 records (about 7,000,000 bytes) from the > fileserver to your machine, and does the entire search on your > machine. Guess how long it takes to download 7MB, even at 38,000 baud? > I know this sounds stupid... But... Really?!?! That sounds like the dumbest design I have ever heard of. What the hell good is a server that does compute? tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) (12/11/90)
In article <1CE00001.i42wj1@tbomb.ice.com> time@tbomb.ice.com writes: > >In article <10559@uhccux.uhcc.Hawaii.Edu>, bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) writes: >> 4D downloads all 70,000 records (about 7,000,000 bytes) from the >> fileserver to your machine, and does the entire search on your >> machine. Guess how long it takes to download 7MB, even at 38,000 baud? >> > >I know this sounds stupid... But... >Really?!?! > >That sounds like the dumbest design I have ever heard of. What the >hell good is a server that does compute? > Tim, In a client/server design, the client program you are running on your mac submits request to a data server. The data server runs on another computer, and carriers out all requests submitted by all clients. The result of the request is then transmitted back to the client. The client never directly accesses the data file. In a file server approach, which is the model that 4D uses, there are no clients. Each mac has its own copy of 4D. Each copy of 4D "shares" its data file with other copies of 4D on the network. And each copy of 4D actually performs the query/insert/delete operations that would have been performed by the single data server described above. Sounds silly, but that's how 4D works. Best regards, Brian K. Martin, M.D. 1103 9th Avenue, Suite 203 Honolulu, Hawai`i 96816-2403 Voice (808) 733-2003 Fax (808) 733-2011 INTERNET: martin@medix.pegasus.com, bmartin@uhccux.uhcc.hawaii.edu ARPA: uhccux!bmartin@nosc.MIL UUCP: {uunet,dcdwest,ucbvax}!ucsd!nosc!uhccux!bmartin
n67786@assari.tut.fi (Nieminen Tero) (12/11/90)
In article <FRANCIS.90Dec11105152@wolfman.cis.ohio-state.edu> francis@wolfman.cis.ohio-state.edu (RD Francis) writes: Path: assari.tut.fi!news.funet.fi!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!tut.cis.ohio-state.edu!wolfman.cis.ohio-state.edu!francis From: francis@wolfman.cis.ohio-state.edu (RD Francis) Newsgroups: comp.sys.mac.apps Date: 11 Dec 90 15:51:52 GMT References: <1CE00001.i42wj1@tbomb.ice.com> <10599@uhccux.uhcc.Hawaii.Edu> Sender: news@tut.cis.ohio-state.edu Organization: Ohio State Computer Science Lines: 27 In article <10599@uhccux.uhcc.Hawaii.Edu> bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) writes: >> 4D downloads all 70,000 records (about 7,000,000 bytes) from the >> fileserver to your machine, and does the entire search on your >> machine. Guess how long it takes to download 7MB, even at 38,000 baud >>? > >That sounds like the dumbest design I have ever heard of. What the >hell good is a server that does compute? > In a client/server design, the client program you are running on your mac submits request to a data server. The data server runs on another computer, and carriers out all requests submitted by all clients. The result of the request is then transmitted back to the client. The client never directly accesses the data file. In a file server approach, which is the model that 4D uses, there are no clients. Each mac has its own copy of 4D. Each copy of 4D "shares" its data file with other copies of 4D on the network. And each copy of 4D actually performs the query/insert/delete operations that would have been performed by the single data server described above. Sounds silly, but that's how 4D works. To risk belaboring the obvious here, that's how all of the Mac databases work, with the probable exception of Oracle. Also, this is how all file servers that I know of work, regardless of whether they're being used with a database or not. Just trying to avoid confusion. -- R David Francis francis@cis.ohio-state.edu Actually there is at least Double Helix III that has it own server that works in a data server fashion as opposed to file server. So Oracle is not completely alone. Even I don't know any more data base programs besides the two mentioned here that would use data server approach. But Double Helix due to its implementation is faster in most operations that the file server counterparts. So I would be interrested to know if somebody tries it over a modem connection. -- Tero Nieminen Tampere University of Technology n67786@cc.tut.fi Tampere, Finland, Europe -- Tero Nieminen Tampere University of Technology n67786@cc.tut.fi Tampere, Finland, Europe
francis@wolfman.cis.ohio-state.edu (RD Francis) (12/11/90)
In article <10599@uhccux.uhcc.Hawaii.Edu> bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) writes: >> 4D downloads all 70,000 records (about 7,000,000 bytes) from the >> fileserver to your machine, and does the entire search on your >> machine. Guess how long it takes to download 7MB, even at 38,000 baud? > >That sounds like the dumbest design I have ever heard of. What the >hell good is a server that does compute? > In a client/server design, the client program you are running on your mac submits request to a data server. The data server runs on another computer, and carriers out all requests submitted by all clients. The result of the request is then transmitted back to the client. The client never directly accesses the data file. In a file server approach, which is the model that 4D uses, there are no clients. Each mac has its own copy of 4D. Each copy of 4D "shares" its data file with other copies of 4D on the network. And each copy of 4D actually performs the query/insert/delete operations that would have been performed by the single data server described above. Sounds silly, but that's how 4D works. To risk belaboring the obvious here, that's how all of the Mac databases work, with the probable exception of Oracle. Also, this is how all file servers that I know of work, regardless of whether they're being used with a database or not. Just trying to avoid confusion. -- R David Francis francis@cis.ohio-state.edu
mlbarrow@athena.mit.edu (Michael L Barrow) (12/12/90)
In article <FRANCIS.90Dec11105152@wolfman.cis.ohio-state.edu> francis@wolfman.cis.ohio-state.edu (RD Francis) writes: In article <10599@uhccux.uhcc.Hawaii.Edu> bmartin@uhccux.uhcc.Hawaii.Edu (Brian Martin) writes: In a client/server design, the client program you are running on your mac submits request to a data server. The data server runs on another computer, and carriers out all requests submitted by all clients. The result of the request is then transmitted back to the client. The client never directly accesses the data file. In a file server approach, which is the model that 4D uses, there are no clients. Each mac has its own copy of 4D. Each copy of 4D "shares" its data file with other copies of 4D on the network. And each copy of 4D actually performs the query/insert/delete operations that would have been performed by the single data server described above. Sounds silly, but that's how 4D works. To risk belaboring the obvious here, that's how all of the Mac databases work, with the probable exception of Oracle. Also, this is how all file servers that I know of work, regardless of whether they're being used with a database or not. Just trying to avoid confusion. -- R David Francis francis@cis.ohio-state.edu Actually, FileMaker (if you classify this program as a database :-) ), uses the client/server approach. That is, each client makes requests of a single machine, which actually reads/writes to the file. I think this topic is _way_ belabored, so I'll shut up now. -- Mike -- --Michael L Barrow mlbarrow@mit.edu o MIT Information Systems/Information Services MCR Consultant o Project Athena Volunteer User Consultant o Member, Student Information Processing Board (SIPB) o Oh, yeah.....I'm a student too! (MIT '93)
a_dent@fennel.cc.uwa.oz.au (12/16/90)
> To risk belaboring the obvious here, that's how all of the Mac > databases work, with the probable exception of Oracle. Also, this is > how all file servers that I know of work, regardless of whether > they're being used with a database or not. Just trying to avoid > confusion. > -- > R David Francis francis@cis.ohio-state.edu > Whilst FoxBASE+/Mac doesn't offer a data server, it DOES has separate data files which allow you to implement your own distributed system. You can have files open locally and a bare minimum of files open on the server (say, just a file to pass transactions through). This feature also allows you to distribute your data across multiple disks and other useful performance enhancements. I really don't know why the many magazine reviews haven't picked up on this before - the centralised database structure of OMNIS and 4D is *SUCH* a pain (yes, I've done a lot of work in 4D so I am qualified to comment). Andy Dent sigless 'cause this is a borrowed machine...