• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 300
  • Last Modified:

Converting to accde files

Greetings all ...

A solution I've just received on a different question is (finally!) providing strong encouragement for me to convert my applications to accde/accdb pairs of files. I'm concerned that coding practices I've adopted in the past won't easily support a conversion to an accde environment. At least not without some serious rethinking and quite a bit of recomposition.

To date the structure I've utilized is basic textbook. Two files, one front end and one back end, both mdb or accdb files. Back end file is all tables, front end file is everything else (including an autoexecute macro), with links to all the tables in the back end. Basic beginner textbook.

The most obvious potential conflict I'm envisioning, as I try to convert at least one of these files to a compiled format, is that I have dozens of instances throughout the front end of my apps where queries, based on conditions available at the moment, are created on the fly, executed, and then deleted. Am I right in assuming that those, at least as they're currently structured, won't run in an accde environment?

Let's assume that my rewriting all instances of this 'create/manipulate/delete' coding methodology isn't an option. Is it possible for me, from within the accde file, to direct that these temporary objects be managed on a workspace within another, linked, read/writable accdb file?

I hope I've articulated this little issue clearly. The implications of your responses, regarding the larger general question of 'how to manage multiple linked files', will clearly have a huge bearing on how I view and map out future projects.

I am so grateful for your willingness to lend your expertise to lost souls like me!

Best,

John
0
jofoco4
Asked:
jofoco4
  • 2
  • 2
1 Solution
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
You cannot create forms or reports in the .accde environment, but you can create/delete queries, if that's what you're asking.

That said, I've rarely found a need to create/delete querie on the fly. You can always just build a temporary query and work with the QueryDef object as needed.
0
 
jofoco4Author Commented:
Thanks for this. My apps don't currently create forms or reports, so I think I'm safe on that front.

One quick followup. I don't understand the distinction you draw between "creating/deleting queries on the fly", and "just build a temporary query and work with the QueryDef object as needed".

This confusion is probably my fault, in how I phrased my first question. Building a temporary query and working with the querydef is how I "create/delete queries on the fly". It's likely your response was just confirming for me that this method is generally accepted.

Thanks again for your prompt reply!

Best,

John
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
By "on the fly", I mean actually creating a QueryDef and populating it.

My description was probably not as clear as it should be. I think you're better off creating and storing a query in the database and then just manipulating that query as needed - i.e. change the SQL property to reflect what you need, then "run" that query. Better yet, just use SQL where possible and be done with it!
0
 
jofoco4Author Commented:
Good thoughts. Thanks.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now