Upgrade an app by copy but leave data sources the same

[Stephen_Ehmann]

FEATURE REQUEST: add an option to “Manage/Versions/App Upgrade/Copy app upgrade from” that causes the copy to not copy the data source pointers.

I want to upgrade a release of an app by copying from a working version of the app but I want to keep the release pointing to the same data sources that it had prior to the copy-upgrade.
Is it possible? Yes
If so, how can I do it? Very manually After App Upgrade, the Google Sheet source used by the application is changed

[Marc_Dillon]

When you make a copy of the app, uncheck the “make a copy of the data”.

[M_Felix]

Hi @Stephen_Ehmann ,

@Marc_Dillon’s reply is correct for your scenario. If you have a working app, example
App1 and you want to clone/copy it then apply updates, just make sure to untick the option for copying table data and file data.

What happens is you will now have 2 applications pointing to 1 data source.
App1 > source 1
App2 > source 1

You can apply your updates in App2 while App1 is left unchanged. However take note

1. You can only do logic updates or other changes that does not involve the data source (ex. text formatting, new icons, formulas etc.).
2. If you need to add new columns to the data source as part of your update for App2, the original application (App1) will stop working since it will no longer recognize the structure of the data source.
   3.If App1 is a LIVE environment used by your users, I don’t think it is good to perform test transactions in App2 while it is using the same data source.

If your scenario is you have a DEVELOPMENT environment and you want to app upgrade your LIVE environment to push new features then the reply in the topic you marked should be the way to go.

[Stephen_Ehmann]

I am aware of what you are describing for “make a copy of table data when copying the app”. That is not what I am asking about.

“If your scenario is you have a DEVELOPMENT environment and you want to app upgrade your LIVE environment to push new features then the reply in the topic you marked should be the way to go.”
→ this is what I am asking about
HOWEVER this is not a Question, this is a Feature Request, I am requesting a feature to fix that horrendous sequence of manual things I have to do.

I am using the “Manage/Versions/App Upgrade/Copy app upgrade from” feature. I want to have this structure:
App A copy 1 → data X
App A copy 2 → data Y
App A’ source → data Z is an upgraded App A (development version)
I want to copy App A’ for both copy 1 and copy 2 and have the resulting App A’ copy 1 and App A’ copy 2 still point to their original data sets.

I have two customers who both need code updates but their data should continue to be pointed to.

[Marc_Dillon]

So you’re asking for a selection to be available, upon initiating an “app upgrade” that asks if you want to use the existing data, or the new data.

I get it. I see how that would help, and especially in your situation.

However just to point out, this feature would be extremely susceptible to inducing large-scale errors. As in, if you made even a single change to the data structure, you’ll mess up the app on the upgrade, and will still have to manually fix that. Such a feature would necessarily have to come with a gigantic warning about this, and because of that I’d be highly doubtful that you’ll ever get this feature.

It sound like you’re attempting to maintain two separate versions of the exact same app, each one for a different client with their own data. I’d highly suggest you look into Security Filters, and/or Private Tables. You should be able to have both clients use the same app, but only see their own data, and you can avoid a lot of this issue in the first place.

help.appsheet.com

Security Filters: The Essentials

You can use Security Filters to control which records a user can see and update.

help.appsheet.com

Private Tables

Learn how to use tables in cases where each user needs their own individual data.

[MultiTech]

Marc_Dillon:

I’d highly suggest you look into Security Filters, and/or Private Tables. You should be able to have both clients use the same app, but only see their own data, and you can avoid a lot of this issue in the first place.

Bump

[Stephen_Ehmann]

I understand and appreciate the private tables pointer. However I want a solution that is more secure and truly keeps the data pointers separate so that there is zero connection from customer A of an app to the data of customer B, both using the same app “code”. I view that as a workaround to achieve the same thing in a less secure way.

@Marc_Dillon regardless of the approach, I still have to fixup the table structures for the other customer, whether the app assists me with not updating the pointers or whether I play the manual games to do the equivalent, my customer B app still won’t load unless I alsoi update data instance B’s structure to match the new app “code”. So I can see this as a valuable feature and if the resulting upgrade of an app with this feature enabled (to not copy the data ptrs) fails to load, that is ok, and is expected, I then need to update that instance’s data sheets.

Core problem:
The data and the app are not truly decoupled and cannot be deployed to production separately in a proper manner.

Conceptually the google sheets themselves are independent of the appsheet data/code. The interface to get them to work together is the column structure implicit “api” that is implemented in the appsheet development UI with errors for mismatches. This particular issue I am pointing out is that this “data” vs. “code” interface is difficult to develop in for some development patterns like the one I want to use.

Broader view:
I want to release my app additionally as “open source”. Overall I have these instances:

• development
• customer A production
• customer B production
• open source

Separately, I plan to write up my challenges with that and solicit feedback on the best mechanism, as well as examples of how other people have done it (if it has been done). The requirements I would like for the “open source instance” are:

• there is zero connection to any customer data
• the open source and production instances can be upgraded from my development app smoothly