Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 35 total |
A few question on V4 |
Tue, Aug 29 2006 4:06 PM | Permanent Link |
"Robert" | Just bought V4 (always late, me) and converted a few apps, so far with few
if any problems. a few questions follow: 1. It seems that C/S is consistently faster in V4 than fileserver (was not the case in V3). Is that everybody's experience? 2. I'm tring to determine a good backup setup (right now I copyfile each DAT and IDX file) using the new backup and restore methods. Questions are: 2.1 In C/S, can I use a Database as backup destination? It seems silly to have to code a path in C/S mode, one should set all that up using the database administrator. 2.2 Can I use the same backup/restore methods when running C/S or fileserver? 3. Is it necessary to do something special to keep the server connection open when the terminal is inactive? If so, what? Robert |
Tue, Aug 29 2006 4:55 PM | Permanent Link |
Jason Lee | > Just bought V4 (always late, me) and converted a few apps, so far with few
> if any problems. a few questions follow: Congrats. I love V4! > 1. It seems that C/S is consistently faster in V4 than fileserver (was not > the case in V3). Is that everybody's experience? I have that experience also. C/S doesn't have the locking "slowdown" that fileserver setups have with multiple users. When you code your application to "think" Client/Server, it even becomes faster. For example, navigating datasets (while...not...eof...next) in C/S mode is faster when Query.RemoteReadSize is set. > 2. I'm tring to determine a good backup setup (right now I copyfile each DAT > and IDX file) using the new backup and restore methods. Questions are: > > 2.1 In C/S, can I use a Database as backup destination? It seems silly to > have to code a path in C/S mode, one should set all that up using the > database administrator. No, although that would be a good feature to have. > 2.2 Can I use the same backup/restore methods when running C/S or > fileserver? Yes. > 3. Is it necessary to do something special to keep the server connection > open when the terminal is inactive? If so, what? You can use the "Ping" feature and set it to ping the server every 60 seconds, for example. Ping is a feature of the TDBISAMSession component. |
Tue, Aug 29 2006 5:20 PM | Permanent Link |
"Robert" | "Jason Lee" <computerguy@wavecable.com> wrote in message news:067A37E1-638A-4F9C-A2F9-3A195D293EE6@news.elevatesoft.com... > C/S mode is faster when Query.RemoteReadSize is set. > Thanks for the feedback. Are the defaults documented soemwhere? Robert |
Tue, Aug 29 2006 6:20 PM | Permanent Link |
Jason Lee | The default for RemoteReadSize is 1. Only one record will be fetched at
a time. This means the client must communicate with the server if you want the next record fetched. If you set RemoteReadSize to 20, however, then 20 records are fetched in a single communication cycle. In code, for example: MyQuery.RemoteReadSize := 50; MyQuery.Open; while not MyQuery.EOF do begin //do something, add client name to ListView, for example MyQuery.Next; end; The query component will grab 50 records at a time from the server, not just 1. If you have 200 records, instead of 200 fetches you have just 4 fetches (of 50 records each). This saves a hell of a bunch of time! Robert wrote: > "Jason Lee" <computerguy@wavecable.com> wrote in message > news:067A37E1-638A-4F9C-A2F9-3A195D293EE6@news.elevatesoft.com... >> C/S mode is faster when Query.RemoteReadSize is set. >> > > Thanks for the feedback. Are the defaults documented soemwhere? > > Robert > > > |
Wed, Aug 30 2006 4:53 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< 1. It seems that C/S is consistently faster in V4 than fileserver (was not the case in V3). Is that everybody's experience? >> Well, it depends upon what the application is doing, and especially if you're using a lot of SQL in the application. C/S is faster with SQL in version 4. << 2. I'm tring to determine a good backup setup (right now I copyfile each DAT and IDX file) using the new backup and restore methods. Questions are: 2.1 In C/S, can I use a Database as backup destination? It seems silly to have to code a path in C/S mode, one should set all that up using the > database administrator. >> No, you have to give it an actual path name. Most of the time backups are executed from the context of the database server machine, either on demand or in a scheduled event. << 2.2 Can I use the same backup/restore methods when running C/S or fileserver? >> Yes. << 3. Is it necessary to do something special to keep the server connection open when the terminal is inactive? If so, what? >> It's not absolutely necessary, but if you want the connection to never time out and be removed by the database server unless the client app/machine has actually been shut down, then set RemotePing to True. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Aug 30 2006 4:55 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jason,
<< The default for RemoteReadSize is 1. Only one record will be fetched at a time. This means the client must communicate with the server if you want the next record fetched. If you set RemoteReadSize to 20, however, then 20 records are fetched in a single communication cycle. In code, for example: >> Just one small addition - DBISAM will automatically adjust the default of 1 to the number of rows in a multi-row control if the DBISAM table/query is being used in a multi-row control like a TDBGrid. It just does this "under the covers". -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Aug 30 2006 5:56 PM | Permanent Link |
"Robert" | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:25A9860E-8B60-420E-8F69-68BCAC883867@news.elevatesoft.com... > > 2.1 In C/S, can I use a Database as backup destination? It seems silly to > have to code a path in C/S mode, one should set all that up using the >> database administrator. >> > > No, you have to give it an actual path name. Most of the time backups are > executed from the context of the database server machine, either on demand > or in a scheduled event. > Hmm, maybe I don't quite understand what you're saying but in my case, the backup happens at a workstation. In fact, nothing is "run" at the server, in the sense that all user interface happens at a workstation. Using the Admin program, I can equate a database folder to an alias, so that regardless of mappings, the workstations all access the same physical files. That's the way it should be. But for backups, each workstation will have to have an actual path. Not consistent. It is not a big deal, I've been dealing with it fine in file server by always using UNC so I don't have to depend on individual terminal mappings. But unless I'm missing something, it seems to me that the backup location should be part of the database setup. Just as you determine that for this database the files are on a specific folder, you should also determine thet the backups go to a specific folder. Just to be consistent. Robert |
Thu, Aug 31 2006 5:53 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< Hmm, maybe I don't quite understand what you're saying but in my case, the backup happens at a workstation. In fact, nothing is "run" at the server, in the sense that all user interface happens at a workstation. >> In that case you'll need to make sure that the the workstation specifies a path that is accessible to the server machine. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Sep 6 2006 7:56 AM | Permanent Link |
"Robert" | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:B0D2EB80-C627-409F-BF58-C90932F95FE9@news.elevatesoft.com... > Robert, > > << Hmm, maybe I don't quite understand what you're saying but in my case, > the backup happens at a workstation. In fact, nothing is "run" at the > server, in the sense that all user interface happens at a workstation. >> > > In that case you'll need to make sure that the the workstation specifies a > path that is accessible to the server machine. > I understand that, I just don't think it's right. There is no reason workstations should have knowledge of "path that is accessible to the server machine". Just as I tell the server to open database alias so and so and the server knows where to find the data, I should be able to request a backup and the server should know where to store the result. At least have an option to tell the backup "put the file wherever the tables are". Otherwise I'm stuck with ini files with hardocded paths even in a pure C/S mode, plus changing from one database to another becomes a drag. Oh well, one can live with that, but it would be nicer if the option were there. I guess I can modify the server to read a server ini file. Robert |
Wed, Sep 6 2006 10:47 AM | Permanent Link |
FWIW, I agree. You should be able to tell the server to use an alias,
which would be stored with the server in something like alias.ini. Thus save to "$backup\myfile.bak" would lookup in alias.ini: backup=c:\mybackup and end up in c:\mybackup\myfile.bak The ideal would be that these could be set per database and by code. Perhaps a wish for ElevateDB? /Matthew Jones/ |
Page 1 of 4 | Next Page » | |
Jump to Page: 1 2 3 4 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |