Problem with built-in backup

[Nathan Zeiset]

For the last several months, we have been having problems with the nightly backups, using Alpha's built-in backup. Almost every time, there are several .ddd files that do not get backed up, because Alpha thinks that they are in use (see attached file). I ran a database compact, which worked fine, with no errors, but when I immediately attempted the backup again, there were several .ddd files that could not be backed up because they were "in use." I attempted to edit field rules for the tables whose .ddd file was in use. Sometimes it claimed that the table was in use, and sometimes it didn't. Any ideas what could be wrong, or how I could troubleshoot this?

[Tom Cone Jr]

When no one else is using Alpha on any workstation, go to the control panel in Alpha. Choose File menu; Choose Database Information. Open tables or sets will be marked.

Is it possible these files were left "in use" on the machine acting as server for your application? If so, have you shut down and restarted the machine that's acting as server for your Alpha application?

-- tom

[Nathan Zeiset]

Thanks for the suggestion, Tom. I'll have them restart the server before the next backup, and report back.

[Ronald Anusiewicz]

Nathan,

You do not say what Alpha build you are using.

I would do what Tom suggested.

If after that you are still experiencing problems, I would submit a bug report. I think that there might be a bug. There are other posts on this board where people can not restructure a table. They are getting the table in use message also.

To confirm that it may be a bug, go back to the alpha build you were using before you had any issues. You may want to do this by coping the entire workspace into a sandbox where you do not have to worry about damaging your live data.

Note: You can have multiple installations of Alpha Anywhere on you computer. This way you can have different builds of AA where you can test before making any changes to the live application. I personally have five different installations of AA, each a different build.

Ron

[Nathan Zeiset]

Thanks for the input, Ron. We are using the current version, but just recently upgraded, and the problem predated the upgrade. Before upgrading, we were using a version that was at least a year or two old.

Nathan

[Ronald Anusiewicz]

I’m using both build 2999 and build 4269 to run different applications. The backup works fine in both along with table restructuring. Just after build 4269, Alpha went with a new version of .net primarily for WEB side development. This required rewriting much code supporting the desktop side of things. In my experience it, it also broke many features on the desktop. I submitted many bug reports and they were fixed.

So if there was a time when your backup did work and then it stopped working correctly, coupled with the fact that others are experiencing a similar error even though they are doing a different task, this still may be a bug.

Ron

[Nathan Zeiset]

This issue was set aside for awhile because of other priorities, but now I'm back to working on it again. I made a copy of the entire database and put it on another computer, opened it up using the same build of Alpha, and the backup worked fine. This leads me to believe that it's not necessarily related to a build issue. The working database is used by several people on a network, but the backup is run at night after all of the users have shut down Alpha. Some of the files that are not being backed up are from temporary tables that are not normally being used, so it seems unlikely that they were even in use the day of the backup. Any other ideas?

[Nathan Zeiset]

Also, I just noticed that of the 18 files that were not backed up last night, all of them were .ddd files, except for one .dbf file.

[Ted Giles]

Suggest you use a 3rd party one.
Datareplicator is a Synology freebie
You can schedule as you wish and include what you want.

[Tom Cone Jr]

Nathan, I suggest you configure the "copy" you made to do its backup overnight. That's a truer test in my opinion. If the same omissions occur in the "copy" look for other processes that are running overnight. Is it possible malware scans are running? Might they open and close your alpha files, preventing alpha from including them in your backups? Another thought: are some of your users logging in remotely during the night?

[Ted Giles]

I thought backup was supposed to close all files, Tom.

[Tom Cone Jr]

Ted, I'm used to running much older versions, so perhaps the backup sequence in Alpha was changed. In earlier versions tables can't be backed up if they're in use. Just like Database Compact restriction.

What Nathan describes is very odd. I'm wondering now if his workspace is entirely located within a single folder (without subfolders ?

Wondering also if he's using a conventional PC or Server to host his application. NAS devices aren't recommended as I recall.

-- tom

[Nathan Zeiset]

Tom, yes, the workspace is entirely located within a single folder.

To test this further, I copied the entire database into a subfolder on the same network drive where the live database is. When I ran a backup on that copy, again a couple of files were not backed up because they were "in use." In this case, there certainly were no other users logging in remotely. (I'm confident that is not happening with the live database either.) There still is a possibility that there is a malware scan interfering. I will check into that.

Nathan

[Ted Giles]

Only other thing I can think of is where the backup is being put.
Windows doesnt like software messing with Prog Files folders,that's why most peole put the apps in a folder outside the Prog Files one.

[Nathan Zeiset]

I have confirmed that the antivirus software does not scan the Alpha folder. The database is on an HP server running Windows Server 2016 Standard. The backup is done to a USB external hard-drive connected to the Alpha computer.

Since it is almost always only a few .ddd files that are not getting backed up, and they are usually for non-essential tables, and it varies from night to night which files are skipped, we will probably just live it, as it's very unlikely that important changes will be permanently lost. Thanks to everyone for your input!