Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 17 of 17 total
Thread DBISAM rollout issues
Tue, Oct 17 2006 10:25 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Paul


That's confused me. If you're running local (ie fileserver) then ports don't even come into it. I'm guessing you're running C/S on a LAN at each location.

Since you say its a 3rd party app - was the Paradox app also 3rd party (the same one I presume) if so I'd go along with they've done a conversion but not optimised it for DBISAM.

Roy Lambert
Tue, Oct 17 2006 1:40 PMPermanent Link

Jason Lee
> Jason Lee, the older machines are Fujitsu Siemenss Scenic Ds and Ns:
<snip>

Thank you Paul. My initial thoughts:

a) the computers should be fine; if you are experiencing the same
problems with different configurations in many sites, then its probably
not the computers; personally, I would junk the Windows ME ones, but I
doubt they are the root of the problem(s)

b) you mention 'ports 12005 & 12006' but then you also say 'local'; in a
typical setup these are mutually exclusive; so a little review is necessary:
1) you have many sites
2) each site has a LAN with the Delphi app running on each computer
3) the apps access shared data residing on a computer connected to the LAN
4) the Delphi app will typically access data on a shared network drive
on a computer in the LAN (this is LOCAL mode, which I like to call
'shared file' mode) *or* the Delphi app will communicate with the DBISAM
database server program (DBSRVR.EXE if using the stock server program)
which accesses the data and sends a response back to the Delphi app on
the workstation (this is Client/Server mode).

Note: A shared network resource (mapped drive letter or UNC resource) is
required for shared file mode, but is not necessary for Client/Server mode.

5) in either case, shared file or Client/Server, DBISAM typically does
not need to be installed on each computer because DBISAM is compiled
directly into the Delphi app

c) If the developer(s) of the app are responsive, they should contact
this newsgroup so we can help them; it's not fair that you are in the
middle between us and them
Wed, Oct 18 2006 8:54 AMPermanent Link

Paul T. Gardner
Jason, thanks again.

Re the OS, we have actually junked ME - those were standard specs as delivered.  All 200-odd machines are
running on Win2K.  Smile

Also, I'm running the risk of making you guys think I don't understand C/S relationships and the differences
between that and a fileserver setup!  In trying to give as much detail as I can I'm explaining around the
situation rather than clearly defining it, so I'll review and organise my thoughts:

1.) *One* machine at each site.
2.) Each site *is* on a LAN, BUT...
3.) Each PC has the Delphi app *and* an instance of DBISAM on the *same* box.
4.) Thus, the network connection is for ordering, updates and data transfer (to head office) only - the app does
not access shared data over the LAN, so as Jason says...
5.)the Delphi app communicates with the DBISAM database server program (DBSRVR.EXE) which accesses
the data and sends a response back to the Delphi app on the workstation (this is Client/Server mode).

Previously I was trying to emphasise that the app and an instance of DBISAM reside on the *same* box.  
Sorry for the confusion.


Wed, Oct 18 2006 10:11 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Paul

>1.) *One* machine at each site.
>2.) Each site *is* on a LAN, BUT...
>3.) Each PC has the Delphi app *and* an instance of DBISAM on the *same* box.

If by "an instance of DBISAM" you mean the server app that could mean that it is c/s, just running on one machine. There's nothing to stop that as an approach but I'd prefer to use fileserver for the local access and c/s for head office.

Can you reveal what the app is?

Roy Lambert
Wed, Oct 18 2006 3:59 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Paul,

<< 1.) *One* machine at each site.
2.) Each site *is* on a LAN, BUT...
3.) Each PC has the Delphi app *and* an instance of DBISAM on the *same*
box.
4.) Thus, the network connection is for ordering, updates and data transfer
(to head office) only - the app does
not access shared data over the LAN, so as Jason says...
5.)the Delphi app communicates with the DBISAM database server program
(DBSRVR.EXE) which accesses
the data and sends a response back to the Delphi app on the workstation
(this is Client/Server mode). >>

I've got the same question as Roy:

Is the configuration such that each PC has its own copy of dbsrvr running as
a separate process ?  Also, is there another dbsrvr process running at the
head office that the application accesses to transfer data, etc ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Oct 20 2006 7:12 AMPermanent Link

Paul T. Gardner
>I've got the same question as Roy:
>
>Is the configuration such that each PC has its own copy of dbsrvr running as
>a separate process ?  Also, is there another dbsrvr process running at the
>head office that the application accesses to transfer data, etc ?

Tim, yes - each PC has it's own copy of dbsrvr running as a separate process, but there is no additional separate process running at head office.  Historically, the app and associated DB
would reside in an independent site (i.e. other customers of the vendor of the app), and at our sites ordering was made over a modem line(!)  Ordering is now made from a central modem
rack, contacted over the network...

Anyway, bit more background, though it seems increasingly likely that the vendor has not optimised the app for DBISAM?  May be time to respectfully ask they contact you guys on this
website.  Then you can start getting at the code and make some real progress.  I'll see what I can do.  Thanks again for your time folks.

Fri, Oct 20 2006 2:35 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Paul,

<< Tim, yes - each PC has it's own copy of dbsrvr running as a separate
process, but there is no additional separate process running at head office.
Historically, the app and associated DB would reside in an independent site
(i.e. other customers of the vendor of the app), and at our sites ordering
was made over a modem line(!)  Ordering is now made from a central modem
rack, contacted over the network... >>

In that case, then I think they really didn't understand how DBISAM worked.
There is no need to run the separate dbsrvr process if it is located on the
same machine as the application.  In such a case, you can just simply
compile DBISAM into the application and access the database tables directly.
Plus, going through the dbsrvr will be slower than direct access in such a
case.

<< Anyway, bit more background, though it seems increasingly likely that the
vendor has not optimised the app for DBISAM?  May be time to respectfully
ask they contact you guys on this website.  Then you can start getting at
the code and make some real progress.  I'll see what I can do.  Thanks again
for your time folks. >>

Yes, please have them contact us.  I'm sure that there is something we can
do to help them correct the issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

« Previous PagePage 2 of 2
Jump to Page:  1 2
Image