This discussion is all very useful. Any thoughts on the relative merits of the Astra solution. It certainly looks to be very simple. It would be typical in my app for data entry to occurr over a 2 hour period every morning. Reporting would be sporadic during the month with moderate use Mondays and (relatively) heavy use in the two days after month end. With Astra, is there a problem reporting from a client site to it's own (remote) printer? Mark Grant Black wrote: > I am not sure I like the suggestions of using Terminal Server or Citrix - > isn't it just the conceptual equivalent of giving your clients PC-Anywhere & > tell them to dial into your server? > > The biggest problem is suggesting running a dial-up line - Telecom charge 4 > cents a minute during the day so if you are talking about a dial up line to > an ISP then you are looking at 8 x 60 x 4 / 100 : ~$20 dollars a day (per > site) or ~30 cents per transaction. It would be cheaper to put in leased > line (only $90 month for a 33.6 last time I looked - admittedly years ago), > and would give you 24/7 uptime. Of course, you still have to connect to an > ISP & pay charges.... good luck finding an ISP that will guarantee uptime > - voyager lost our link for a couple of hours last week :-(. > > Its just a personal opinion, but I think that PC's are cheap enough that > running dumb terminals just seems wrong. > > If you want to keep _running_ costs down, then I would be asking the > questions about how fresh the data needs to be for reports & the uptimes > required. If you have something like a on-line booking system then > real-time transactions are going to be important. For a more typical POS > type system with nightly (off-peak) reconcilations, then something like the > Astra or Midware looks interesting but you are going to have to think about > the data flows very carefully. > > If you already have the app running on the LAN & the company seems value in > installing a WAN (hopefully not just for your app), then its not a problem - > just get a network consultant in to set up a WAN link (frame-relay, leased > line, ISDN - get them to do quotes). All you have to do is to make sure your > app is not too bandwidth intensive - ie check you are not using TTables on > large datasets or doing select * on big tables & joins. Unless you have a > badly designed database or large datasets you shouldn't choke a ADSL link at > the server end. > > > > The Remote sites are not in cities and may not have access to ADSL > > > Do these alter your suggested solution? > > > > With Citrix, you can use dial up and configure it to > > reconnect (without losing your session) when the line drops out. Quite > > good really. > > > > Seems funny to me that Terminal Server (with the application > > > residing on the > > > server) is a better solution than having the application on > > > each site with only > > > the database on the server. Comments? > > > > With YOUR particular situation, its OK. It also keeps your > > costs down, as > > you only need to install your application *once* at the > > server. You can > > also configure WinFrame so that you can dial in to do remote > > support. The > > client machines don't need super CPUs, even a lowly 286 will do! > > > > > > Regards, > > Dennis. > > > > -------------------------------------------------------------- > > ------------- > > New Zealand Delphi Users group - Delphi List - > > [EMAIL PROTECTED] > > Website: http://www.delphi.org.nz > > > --------------------------------------------------------------------------- > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz
begin:vcard n:Howard;Mark tel;cell:(021) 477 564 tel;fax:(07) 348 8178 tel;work:(07) 348 8177 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Forest Production Systems Ltd end:vcard
