Guidance moving from a5v5 to a5v11

[Rinova]

Hi everyone,

I moved a A5V5 database from an old server to a new server with A5V11 installed on it. It went well for about a month and then I noticed some issues with memo fields corrupting. I must have done something wrong.

I don't think the problem is A5V11, I think the problem is with the actual new server setup. I started looking into the tables details | Field Rules and found a bunch of references using the old server name. I am planning on taking the last good backup that does not contain corrupt memo fields and restoring to the new server but this time I will rename the server to match the old server name.

The old A5V5 was setup to use UNC paths that pointed to the database files (I'm guessing this was done so everyone could access the data files on the server through the shadow databases that were setup on each desktop)

Q1. Should I rename the new server to match the old server name? BTW the old server is not on the network so no worries with naming conflicts.
Q2. The desktop PC's are setup with shadow databases. How do I update the desktops? Do I uninstall and re-install?
Q3. After installing Network Optimizer on the desktops it asks to install SQL server, why does Network Optimizer need to install SQL Server on the desktops?
Q4. This question is not that important... Does Alpha Five have a native odbc connection or something compatible to connect to a Cobol database?

I'm not sure if this is the correct way of moving the database so any other suggestions on how to do this would be appreciated. I apologize if my post is confusing.

Thank you,
Rich

[Rinova]

Re: Guidance moving from a5v5 to a5v11

Isn't it amazing how after you post for help you find out what the problem was (at least I think I found the solution LOL).

I looked at the table details and found that a couple of field rules in the lookup tab had incorrect paths to the table. The paths were pointing to location on the old server. I'm guessing this is what cause the memo corruptions. Correct me if I'm wrong PLEASE!

To fix this I copied all the memo records to a new table and then matched the table rules, Indexes and Structure from the old table to the new table and corrected the database paths in the table rules lookup tab. Copying the records to the new table fixed the corrupt memos.

FYI - When I copied all the memo records (including the corrupt ones) I noticed the corrupt memo fields were empty / blank I guess this is how Alpha fixed the corruption (by removing the text in the memo field). I'll just copy the text from the corrupt record into the fixed record (All 80 of them blahhh).

My next task is to figure out a way to automate daily backups. Anyone have suggestions on this? (I'll search the Forum for this and if I don't find a solution I'll post)

Thank you,
Rich

[martinwcole]

Re: Guidance moving from a5v5 to a5v11

Just for the record, I don't think you can "rename" Server 2008 and up.
Sounds like you found a solution - Congrats
Also, on all my shadows, we use a mapped drive

[Rinova]

Re: Guidance moving from a5v5 to a5v11

Martin,

What file/folder permissions do you use for the mapped drive? Do you install the My SQL Server on each desktop after installing Network Optimizer? Very confused about this.

Thank you,
Rich

[martinwcole]

Re: Guidance moving from a5v5 to a5v11

I don't use sql - dbf only
making a mapped drive is simple
use windows help to find out how
example: drive "S" on your local computer is actually a drive or folder on the server
on the server you set the drive or folder to be shared

[Rinova]

Re: Guidance moving from a5v5 to a5v11

Thanks Martin, I appreciate the help.

[DaveM]

Re: Guidance moving from a5v5 to a5v11

Also, on all my shadows, we use a mapped drive

90% of my shadowed installs use the server name and not a mapped drive.
\\servername\folder\whatever.adb
less chance for an end user to mess up a database accidentally. People are curious and will go looking through drive letters, but tend to do a lot less of that with my method.
More importasntly, you can create a shadowed app on one computer and copy it to 10-20 other computers with no other work, where with mapped drive, somebody will have to sit at each computer and map the drive. Hopefully all the computers will have the same drive letter to the server.
I prefer the less work and less confusion method.

How simple? when making the shadow, just navigate to the named sever, folder and adb file. Create the shadow. Kind of similar to what you do to create a mapped drive, but you only need to do it one time and then just copy the shadow folder to all the other user's machines. That can even be copied from the server as well with a small app or by hand quicker than making a mapped drive letter and then creating a shadowed copy on each computer.

I actually can send the mapped, shadowed copy in an installer where the client simply runs the installer on each machine.

Note: the 10 percent mapped drive was where the client had already spend the hours making a mapped drive on each computer throughout their business. I saw no reason to further confuse them. When the got the installs, I had duplicated their setup and all they had to do was the install of the shadow that was already set up to access their M: drive. My installer placed runtime and shadowed copy on the workstation. I also had the server portion bumped by 1 so each first start up refreshed the shadow automatically.