Windows 10: Lotus Approach .dbf read-only warning after splitting RAID 1 array

Got a bug here that is driving me crazy. I had Windows 10 Pro V1709 32bit running on RAID1 (mirrored). This PC was running very slow after KB4074588 (but that is another story), so I decided to replace the two mirrored 500GB HDDs with a 500GB SSD.

Step one was to disable raid at boot up. No problems there. Next, change the SATA RAID option in BIOS to AHCI, and do a Safe Boot into the OS, then a normal restart. No problems there. Successfully changed Windows from RAID to AHCI using this guide:
https://triplescomputers.com/blog/uncategorized/solution-switch-windows-10-from-raidide-to-ahci-operation/

I then installed the Samsung EVO 860 500GB SSD, using the Samsung migration software to clone the two partitions on the HDD (OS and DATA partitions).

We use the ancient Lotus Approach database software (Lotus Smartsuite V. 9.8). The program is installed on C: drive (where Windows resides) and the folder with the database resides on a partition called DATA (E*Smile on the same HDD. After cloning the HDD to the SSD, the .dbf files on DATA partition (now on the SSD) are all read-only. If I open the database on the source HDD, it opens without the read-only warning. I thought this might be a Windows permissions problem, so I deleted the database folder on DATA SSD partition and used XCOPY /O /X /E /H /K to copy all permissions. Still got the read-only warning.

Tried to change the read-only permissions in Lotus Approach. File menu, choose User Setup --> Approach Preferences --> Database panel, but the "Make all fields in database read only" checkbox has a greyed out tick which I cannot remove. So I thought this might be something to do with the database being on the SSD.

I next booted up using one of the originally mirrored HDDs, but this time I got the same problem with the HDD; Approach produced the read-only error on the DATA HDD partition (which had formerly produced no error when I booted from the SSD), but strangely, if I opened the database files on the DATA SSD partition, they now open without the read-only warning. It seems that since I split the RAID mirror, Lotus approach gives me a Read-Only message if the database files are stored on the same disk as the OS. This happens both on the SSD and the HDD. If I boot from a particular disk (SSD or HDD), I can only avoid the read-only warning by opening the database files on a partition on another disk.

What I want to do is remove the HDDs and just use the SSD, but since access to the Approach database is critical, I can't do this without solving this issue.

Hope somebody out there might release what is causing this.

Many thanks,
Tim

:)

 

RAID 0 went from NTFS to ReFS after 1703 updated to 1709.

More of a statement then an actual question.

my UEFI RAID Array was working on Windows 10 Pro 1703. After a FORCED update to 1709 from windows (not my choice) my RAID was set to being a ReFS partition.

When I ended up rolling back my Windows update, Windows 1703, it could no longer read my raid (it would only show as a RAW).

I am now forced to work with a glitched 1709 update as that is the only way my RAID can be read as I get it backed up before reverting my build to 1703, re-partitioning the RAID Array, and finally restoring all of the data.

Windows, you are being a pain in the rear with this update, please stop forcing updates if they are going to change things like this?

Thanks,

Boxkid

 

RAID 10 and Windows 10

OK - I'm stumped. I have an Alienware Aurora with a 4 drive RAID 10 array. I recently upgraded from Win7 Ultimate and I can't find Intel RST drivers. The RAID 10 array is still there but it appears to be in a verify state. But - since I don't have any
Intel RST software running - how do I check the status of the RAID 10 array/disks.

Computer management seems to think it's a RAID 1 array.

 

Have you tried using Easus's free partition managing tools? It can show a lot of reasons why the Data partition may be foreign to the bootable drive and may even offer solutions..

Easus.

 

I tried cloning the DATA partition with Acronis True Image, but got the same issue. Perhaps this is a Lotus Approach issue.

 

Fixed this. Cloned again with True Image and this time i worked