ACCDR changes in Run Time Environment (1 Viewer)

[ASherbuck]

This problem is making my ::boggle::

In two separate locations with different users I have had an issue where they have somehow made changes to their front ends when the front end is saved as an ACCDR.

Their computers only have the 07 run time installed. It was my understanding that no changes could be made to a file saved with the ACCDR. However, after a few weeks of use the Access 07 save box came up on the screen with the list box of options asking if you would like to save, not save or cancel. If the user hit yes then some of the controls who have their visible property changed to false during use have their default visibility property changed to false.

So the next time the package is run the controls just don't show up at all.

Is this possibly some type of corruption or am I overlooking something?

 

[mcdhappy80]

This problem is making my ::boggle::

In two separate locations with different users I have had an issue where they have somehow made changes to their front ends when the front end is saved as an ACCDR.

Their computers only have the 07 run time installed. It was my understanding that no changes could be made to a file saved with the ACCDR. However, after a few weeks of use the Access 07 save box came up on the screen with the list box of options asking if you would like to save, not save or cancel. If the user hit yes then some of the controls who have their visible property changed to false during use have their default visibility property changed to false.

So the next time the package is run the controls just don't show up at all.

Is this possibly some type of corruption or am I overlooking something?

If the file is saved as ACCDR, and that was the only thing you did to secure your database, than any user could restore it to original functionality by just renaming it back to .accdb.
You need to make your database .accde to prevent others from modifying your work, but be sure to make backup of original database before converting, because once you convert you cannot change back.

 

[ASherbuck]

Yes, thank you for the reply.

What I'm saying is the changes were made while the file was of the accdr file extension.

Only the run time of ACC07 exists on their machines so it's not like they were able to get anything out of changing the extension, if they did.

 

[mcdhappy80]

Yes, thank you for the reply.

What I'm saying is the changes were made while the file was of the accdr file extension.

Only the run time of ACC07 exists on their machines so it's not like they were able to get anything out of changing the extension, if they did.

Maybe I didn't express myself nicely .
It doesn't matter what is installed on their machine (runtime or full access).
What I'm saying is:
if the only method you took, to protect your database, was renaming it to .accdr (to make it hide all the design features when it opens), they could have easily copied that .accdr database you gave them, take it to some machine where full access 2007 is installed, change the extension back to .accdb, and then change everything.

 

[gemma-the-husky]

maybe you have some code calling this dialog box in some place?

 

[ASherbuck]

mcd I understand exactly what you are saying. I know exactly where you are going with this. I am attempting to cut you off at the pass and explain that is not what happened. Specifically, I am asking if their are any known bugs or anomalies present in ACC2007 where a file saved under that extension can somehow change. Be it corruption or something overlooked.

Gem I've included a SS for clarity. I know the vba window is opened behind me, I just happened to be looking at that at the time when I snagged that shot. That's the box popping up during run time.

Since the original post I have been able to replicate to verify that this is indeed happening within an ACCDR in a run time environment. It has occured, seemingly at random.
My method for testing involved two separate machines, both setup with the same version of windows, same access package and same run time. I ran identical steps within both front ends, at seperate times I would receive this save window independent from each other. Sometimes I would have to go through certain controls/processes in the package multiple times before I would encounter this problem.
I made a copy of the FE each time and attempted to examine the changes that had taken place, it appears the default visible properties are being changed if I answer yes. The VBA behind the form does indeed change these properties but only temporarily, for some reason this save box is allowing those visible properties to stick around.
So when the form is reopened controls that are necessary are hidden instead of shown.

 

[boblarson]

Question - Are you using any QueryDefs in code? If so, are they "hanging around" so to speak and therefore might need to be set to NOTHING so that there is nothing to save (I only ask due to the Query1 and Query2 screenshot).

 

[dfenton]

Are you absolutely certain that full Access is not installed on the machines in question? If you installed your app as a runtime app, it won't neuter a pre-existing full Access installation.

And are you saying they changed the data, or the design of tables/forms/reports/etc.?

If you don't want your users changing the front end, don't distribute anything but an ACCDE renamed as ACCDR.

Keep in mind that if they have full Access all they have to do is rename it to be able to change it.

 

[boblarson]

And are you saying they changed the data, or the design of tables/forms/reports/etc.?

If you don't want your users changing the front end, don't distribute anything but an ACCDE renamed as ACCDR.

Remember David, an ACCDE or MDE, you can still change table or queries, if you use a full version. But I believe that using code in an ACCDE or MDE to work on QueryDefs can cause some of what was shown here.

 

[boblarson]

Well, I just tested and it seems that creating a querydef via code will not cause the save as message. Back to the drawing board.

 

[ASherbuck]

Thanks for the attention bob and dfenton,

I'm certain that there are no querydefs being used. In another section of I make use of Tabledefs, but my problem is that the form design is changing, not data. If I was able to upload a front end I would but that's not something I'm allowed to do.

What I have done so far is treat this like the database is corrupted. I've made an empty DB and just copied all the forms/queries/reports/vba over. I'm going to give this a shot and see if I'm able to elicit a similar problem from the new front end.

 

[gemma-the-husky]

it is saving the queries, query2 and query3

so, are these real queries, or run time queries

is it possible that you are changing the sort order, or some other query property in code, that might cause the dialog box. - this still doesnt explain the forms changing.

--------
however a runtime dbs is still a full dbs, that would be completely visible to anyone with the full environment. Why not use a mde and see if that sorts it - at the very least, you might get a run time error, if something in your code IS trying ot change a form.

 

[ASherbuck]

That picture I included was only to demonstrate the dialog box that is popping up for clarification. It is not saving 2 new queries. I created those queries in a different database in order to get you a screen shot to show what dialog box is showing up.

Within the accdr the dialog box asks to save the form name or the form that is having the problems.

Once again, the problems I am having deal with form controls on a design level where seemingly randomly my forms are changing on a design level when the default visible properties are being changed to false.

 

[dfenton]

Remember David, an ACCDE or MDE, you can still change table or queries, if you use a full version. But I believe that using code in an ACCDE or MDE to work on QueryDefs can cause some of what was shown here.

If the OP is worried about changes to data, then I'm flabbergasted. I don't know where anyone would get the idea that the runtime would somehow protect *data* from editing. I thought the issue was DESIGN changes, either in tables or forms/reports/etc. Those should not be possible with the runtime, as it blocks the UI for making design changes.

ACCDE/MDE has nothing to do with design changes for anything but code-bearing objects, which anyone who takes the time to read the help file describing what it does would understand. That is, a back end should never be an ACCDE/MDE, since it won't have any code in it.

 

[ASherbuck]

Dfenton nailed it.

These are design changes that are occurring on my forms through the run time. There is no problem with data anywhere.

 

[dfenton]

Dfenton nailed it.

These are design changes that are occurring on my forms through the run time. There is no problem with data anywhere.

Then the machines that you think have only the runtime actually have full Access, or the users are taking the database to a machine with full Access installed.

That is the only possible conclusion.