We have had a dbisam c/s system running on a Windows 2000 Pro computer
for some years (since 2004, I think).  I'm not quite sure of the dbisam
versions, but I think the server (RemoteEngineVersion) is 4.21 (and my
component set for the client applications is 4.22 b6).
This computer is starting to behave erratically, and we may have to move
everything to another machine.  The new machine will probably be running
"Windows server 2008 R2 SP1 (64bit)".  We have considered a move some
years ago, but now it seems it cannot be postponed for much longer.

1. What is the simplest way to get the server running on the new
computer?  Will a "standard" install be sufficient - this being a
Windows version for which dbisam/4 never was intended.
2. How do I move users (usernames/passwords) - is there a file I can
copy or some registry entries that can be transferred?

Is there a FAQ, Technical Bulletin/Artice offering help on this?
Any advice concerning such a move will be appreciated.


TiA
Aage J.

Aage,

The simplest way, which I have performed before, is to perform a
standard installation into the same directory name you have on your
current machine, then copy the files from the current machine to the
new machine. You have to make sure you do install the DBISAM service on
the new machine as well. Note: You will not be able to copy all the
files from/into either machine while the service is started/running on
the machine.

While I have not worked with Windows server 2008 R2 SP1 (64bit) I don't
believe there would be an issue. I am running the current version of
DBISAM on a 64bit Windows 7 box with no issues. I happen to have it
installed in a C:\DBISAM directory.

> How do I move users (usernames/passwords) - is there a file I can
copy or some
> registry entries that can be transferred?

When you copy the files from your current machine it will take care of
the users as well. The important files there are the dbsrvr.lgb, the
dbsrvr.scb, the dbsrvr text file and the dbsrvr Windows Explorer
Command files (sorry but I don't know what the extension is on that
last file. It just shows on my Win7 64bit machine as "Windows Explorer
Command"). If you have created a server configuration file, you will
need to copy that file over as well. Those filed contain all the
pertinent information the server needs.

I hope this helps you get running on the new machine.

---------------------
Jan Ferguson [Team Elevate]


Aage Johansen wrote:

> 1. What is the simplest way to get the server running on the new
> computer?  Will a "standard" install be sufficient - this being a
> Windows version for which dbisam/4 never was intended.  2. How do I
> move users (usernames/passwords) - is there a file I can copy or some
> registry entries that can be transferred?
>
> Is there a FAQ, Technical Bulletin/Artice offering help on this?
> Any advice concerning such a move will be appreciated.

What install are you referring to?

The install from Elevate website is needed to get dbisam components
registered in IDE - none of that is required for dbsrvr (end user)
deployment.

Easiest install method is simple file-copy. Assuming you're using the
dbsrvr as shipped by Elevate everything is contained in the same folder
- this includes server configuration and users - so you just have to
copy the folder to the new server.

Few things to keep in mind:

1. Databases - are those absolute or relative paths on the old server?
You need to copy database folders over together with the dbsrvr folder
and then use server manager to update the DB paths.

In our case we use relative paths so data is in subfolders of the dbsrvr
so we just copy the folder tree and never have to reconfigure as db path
does not change..

2. if your dbsrvr is bound top specific IP (instead of default of all
IPs) then update the ini file with the new server ip

3. I would not recommend putting data into "c:\program files" but rather
i'd use a custom folder off the root of drive (e.g. c:\mydata) as you'll
avoid file redirection and other permission issues.

4. run the dbsrvr first in interactive mode so you can allow firewall
exceptions and make sure everything works

5. to register the dbsrvr service i usually just launch a command prompt
with admin rights to avoid permission issues again.

We have number of clients running dbsrvr with server 2008r2 and it works
fine

Good luck

Raul


On 9/20/2012 3:44 PM, Aage Johansen wrote:
> 1. What is the simplest way to get the server running on the new
> computer?  Will a "standard" install be sufficient - this being a
> Windows version for which dbisam/4 never was intended.
> 2. How do I move users (usernames/passwords) - is there a file I can
> copy or some registry entries that can be transferred?
>
> Is there a FAQ, Technical Bulletin/Artice offering help on this?
> Any advice concerning such a move will be appreciated.
>
>
> TiA
> Aage J.

Aage,

Raul is correct regarding the "installation". I had a brain
fart...since I always install in my IDE here and then my application
installations handle the copying of the server application and required
files, I didn't take that into account. I did cover that in the
remainder of that paragraph but I probably mislead you on the "standard
installaion".
--
Jan Ferguson

On 20.09.2012 23:14, Raul wrote:
> What install are you referring to?
Good question.  So many years since last time - I've forgotten what I
did then.

>
> The install from Elevate website is needed to get dbisam components
> registered in IDE - none of that is required for dbsrvr (end user)
> deployment.
>
> Easiest install method is simple file-copy. Assuming you're using the
> dbsrvr as shipped by Elevate everything is contained in the same folder
> - this includes server configuration and users - so you just have to
> copy the folder to the new server.
>
> Few things to keep in mind:
>
> 1. Databases - are those absolute or relative paths on the old server?
> You need to copy database folders over together with the dbsrvr folder
> and then use server manager to update the DB paths.
I don't recall - have to check.  Probably an "absolute path".
>
> In our case we use relative paths so data is in subfolders of the dbsrvr
> so we just copy the folder tree and never have to reconfigure as db path
> does not change..
>
> 2. if your dbsrvr is bound top specific IP (instead of default of all
> IPs) then update the ini file with the new server ip
Any IP, I think.

>
> 3. I would not recommend putting data into "c:\program files" but rather
> i'd use a custom folder off the root of drive (e.g. c:\mydata) as you'll
> avoid file redirection and other permission issues.
Right.
>
> 4. run the dbsrvr first in interactive mode so you can allow firewall
> exceptions and make sure everything works
>
> 5. to register the dbsrvr service i usually just launch a command prompt
> with admin rights to avoid permission issues again.
>
> We have number of clients running dbsrvr with server 2008r2 and it works
> fine
Good to know.  I assume you are using 64bit.
>
> Good luck
>
> Raul

Thank you (and to J.B.F, as well).
I have a dbisam folder structure: "C:\dbisam" with two sub-folders:
"addition" and "cs".  There are (among other files) dbsrvr.exe,  -.lgb,
-.scf and -.scb.  The last one is perhaps a backup?


--
Aage J.


>
>
> On 9/20/2012 3:44 PM, Aage Johansen wrote:
>> 1. What is the simplest way to get the server running on the new
>> computer?  Will a "standard" install be sufficient - this being a
>> Windows version for which dbisam/4 never was intended.
>> 2. How do I move users (usernames/passwords) - is there a file I can
>> copy or some registry entries that can be transferred?
>>
>> Is there a FAQ, Technical Bulletin/Artice offering help on this?
>> Any advice concerning such a move will be appreciated.
>>
>>
>> TiA
>> Aage J.
>

Aage,

>> We have number of clients running dbsrvr with server 2008r2 and it works
>> fine
> Good to know.  I assume you are using 64bit.

Yes - 2008r2 was 64 bit release only so there is no 32bit for r2.

> I have a dbisam folder structure: "C:\dbisam" with two sub-folders:
> "addition" and "cs".  There are (among other files) dbsrvr.exe,  -.lgb,
> -.scf and -.scb.  The last one is perhaps a backup?

The subfolders are specific to you - maybe data or such.

Yes - scf is the main config file for server and scb is backup of the config. lgb is the log file backup.

Raul

> Good to know.  I assume you are using 64bit.

Yes - 2008r2 was 64 bit release only so there is no 32bit for r2.

Just clarify - OS is 64bit. At this time we still use 32bit dbsrvr

Raul

On 24.09.2012 04:14, Raul wrote:
>> Good to know.  I assume you are using 64bit.
>
> Yes - 2008r2 was 64 bit release only so there is no 32bit for r2.
>
> Just clarify - OS is 64bit. At this time we still use 32bit dbsrvr
>
> Raul
>


Thank you.
Delivery of the new server should be next week.  I think this will be
just fine (famous last words...).

--
Aage J.

Aage,

<< I think this will be just fine (famous last words...). >>

Its going to work fine, I believe.
Just as Raul, I also have a DBISAM 32 bits server running on a Win 2008 R2, and its been working fine.
The only difference is I'm running the latest DBISAM version, but I have been running all DBISAM versions on the same 2008 server for since it has been released, so...

--
Fernando Dias
[Team Elevate]

On 24.09.2012 21:12, Fernando Dias wrote:
> Aage,
>
> << I think this will be just fine (famous last words...). >>
>
> Its going to work fine, I believe.
> Just as Raul, I also have a DBISAM 32 bits server running on a Win 2008
> R2, and its been working fine.
> The only difference is I'm running the latest DBISAM version, but I have
> been running all DBISAM versions on the same 2008 server for since it
> has been released, so...
>
> --
> Fernando Dias
> [Team Elevate]


We're getting there...

It seems we can use the database from a remote client, reportedly as a
client/server system.
However, srvadmin refuses to work.  Last time I tried to start it there
was a pause (for some longish seconds), and an error message ("216", IIRC).
Initially, some file(s) was/were not copied to the new machine (probably
reserved by som dbisam thingy).  I think this was fixed, but still no
cigar.  I haven't personally been present and watched the latest
proceedings, only been informed of progress (or not).

Any clues about the "216"?
I've been thinking "UAC trouble", but we've always logged in as
Administrator (as this is the only user!).

--
Aage J.
The machine also hosts a few Firebird (2.5.1) databases, this works well.