Hi guys, good day to y'all !
So, I have a client where I have deployed an application. The customer runs a runtime install. Versions of the runtime and the used development application are equal, build numbers are equal (checked!).
The developed application runs smoothly on the customers' computer.
When I want to deploy some upgrades/updates to the app, this is were the horror experience starts.
What I do is create a backup on the development machine with the latest statusquo, and make sure I only select application files in the files tab of the backup window. So, no data will be overwritten. And in itself, that works perfectly so that is not the problem. Next, I go to the client, and first make a total backup of the latest status of the customers application and data, and secure that backup for possible later use. I create 2 backups, 1 total, and 1 only the data files for possible use later if needed.
Next, I restore the backup I made on the development machine with the latest software (app files only!).
What happens is, that I get error messages telling me that stuff is missing, messages that there are ajax problems, and messages that some stuff on the webcomponents can not be loaded. I have no clue why that is the case. I have a hunch though, and I would like to run that hunch through this community so someone can confirm or, maybe, have better ideas on what's going wrong here.
The customer runs a Windows 11 machine, where the database is located on the c: drive in an application map. In order to share the database with other users on the customers "network" (which in fact is only a windows group!) I have assigned a drive letter to the database directory so other machines can point to that drive easily. This assigned drive letter is Z:
I have set this drive Z: to allow sharing of files, and I can approach it from other machines where also Runtimes are running. I have not pulled a shadow until now, so it is not yet "network optimized". As the traffic over that shared node is not that heavy, it seems not yet needed and it is a bit easier to update the main database.
However, something is not going right. I constantly get these errors. At first, I thought maybe my backup from the development machine wasn't right, and went and made a new one, checked it thoroughly, went back to the customer where I experienced exactly the same problems with these errors. I suspect, the backup I made also takes into account my own drive letter and file locations? So when I open the customers database from Z: and then run the restore, will it write the restored files back to the original c: location? I have no clue, since this drive letter Z: ofcourse is nothing more than a link to the c: drive on the customers machine. So the files end up there anyways. Looking outside the designated drive letter Z: I can find the database on c: as well.
Bottom line: I am flabbergasted on what goes wrong here. This should be a flawless procedure in order to make it work. If I have to invest 4 hours per update this is not going to work.
Ofcourse, I am doing something wrong. I know that. I am not blaming the software in any way, shape or form. It's me. Something is going wrong, and the problem is that I simply do not grasp what it is exactly.
I already have pinpointed issues with the automatically generated autoexec file from the Alpha Anywhere menu. That function incorporates a hard link to the database which demands a 100 procent equal location of files on development/customer machines. So I found out I have to manually adjust that in the generated autoexec. file after creation. And that solves that problem. So, my first thoughts were that there was something similar going on here.
Somebody have an idea ?
So, I have a client where I have deployed an application. The customer runs a runtime install. Versions of the runtime and the used development application are equal, build numbers are equal (checked!).
The developed application runs smoothly on the customers' computer.
When I want to deploy some upgrades/updates to the app, this is were the horror experience starts.
What I do is create a backup on the development machine with the latest statusquo, and make sure I only select application files in the files tab of the backup window. So, no data will be overwritten. And in itself, that works perfectly so that is not the problem. Next, I go to the client, and first make a total backup of the latest status of the customers application and data, and secure that backup for possible later use. I create 2 backups, 1 total, and 1 only the data files for possible use later if needed.
Next, I restore the backup I made on the development machine with the latest software (app files only!).
What happens is, that I get error messages telling me that stuff is missing, messages that there are ajax problems, and messages that some stuff on the webcomponents can not be loaded. I have no clue why that is the case. I have a hunch though, and I would like to run that hunch through this community so someone can confirm or, maybe, have better ideas on what's going wrong here.
The customer runs a Windows 11 machine, where the database is located on the c: drive in an application map. In order to share the database with other users on the customers "network" (which in fact is only a windows group!) I have assigned a drive letter to the database directory so other machines can point to that drive easily. This assigned drive letter is Z:
I have set this drive Z: to allow sharing of files, and I can approach it from other machines where also Runtimes are running. I have not pulled a shadow until now, so it is not yet "network optimized". As the traffic over that shared node is not that heavy, it seems not yet needed and it is a bit easier to update the main database.
However, something is not going right. I constantly get these errors. At first, I thought maybe my backup from the development machine wasn't right, and went and made a new one, checked it thoroughly, went back to the customer where I experienced exactly the same problems with these errors. I suspect, the backup I made also takes into account my own drive letter and file locations? So when I open the customers database from Z: and then run the restore, will it write the restored files back to the original c: location? I have no clue, since this drive letter Z: ofcourse is nothing more than a link to the c: drive on the customers machine. So the files end up there anyways. Looking outside the designated drive letter Z: I can find the database on c: as well.
Bottom line: I am flabbergasted on what goes wrong here. This should be a flawless procedure in order to make it work. If I have to invest 4 hours per update this is not going to work.
Ofcourse, I am doing something wrong. I know that. I am not blaming the software in any way, shape or form. It's me. Something is going wrong, and the problem is that I simply do not grasp what it is exactly.
I already have pinpointed issues with the automatically generated autoexec file from the Alpha Anywhere menu. That function incorporates a hard link to the database which demands a 100 procent equal location of files on development/customer machines. So I found out I have to manually adjust that in the generated autoexec. file after creation. And that solves that problem. So, my first thoughts were that there was something similar going on here.
Somebody have an idea ?
Comment