Store value after code execution

[gdesreu]

Hi guys, I am executing code that converts my queries between postgres tables and access tables, that code works great. What I'm trying to do is store the mode type I'm using (postgres or access) somewhere in a safe spot so that I can read it when the database is opened and determine if the database is in Access mode or Postgres mode. I can then use it to automatically choose the right tables in some of my other code.
Basically after it finishes updating the qdf.sql I want it to store whatever mode was last selected. I'm hoping to display it on a user form when it opens and then I think I can take it from there. Whats the best way to handle this. Any ideas?

 

[gdesreu]

You are continually modifying the sql property of 1 or more queries. This can cause corruption at worst (not that it will - it's one of several possible contributing factors), and db bloat in the least (more likely). So you appear to be correct in that it is your FE (front end) that will corrupt (if ever), which would still not be acceptable to me and may fail in the middle of a table update (the main thought behind my corruption concern), so it matters not that the db is split, but that's just the way I am. I mean, would I want to create something that I know can break at the worst time (Murphy's Law?)? Would I be comfortable in knowingly producing a vulnerable tool? Not ever. That doesn't mean you should look at things the same way - just giving you my perspective.

I would like to always do things in the most correct way possible. Doing things the incorrect way isn't a good way to learn or move forward productively. If this is a bad idea then I don't want to do it. I'm a little fuzzy still on your temp process but am definitely open to it. For large projects, I am most likely going to make this switch once...to postgres and then not back again, but that may not be true 100% of the time but is my best guess going forward. For smaller ones access backends are perfectly fine for our needs. I did this because I didn't want to carry two different front ends around. My front end is basically a generic template that is used for all projects and is updated periodically to improve efficiencies in how we handle our data or for clients needs etc., When large projects come in that exceed access limitations I would need to move the data to postgres but keep that move transparent to the end user. That's essentially my process. I'm all ears as to how best to handle that from more experienced programmers.

 

[xenou]

FWIW, I don't think it is a concern to update the sql definitions frequently.

 

[Micron]

OK, it was my interpretation that this would be switched back and forth very frequently. If not, as you say, then I agree with xenou, not a big deal.
As for being fuzzy, did you read up on the temp qdef? It simply exists only in memory - not in the Nav pane. Practically the same thing, it's just virtual. It dies same as any other memory object (like a recordset) when certain things happen.

If nothing else, you're now aware of it and can use when needed. As I said, if I recall correctly, it even works with tables. Didn't mean to drag this out; was just trying to introduce an option that wouldn't contribute to corruption. Turns out it's not a concern.

 

[gdesreu]

OK, it was my interpretation that this would be switched back and forth very frequently. If not, as you say, then I agree with xenou, not a big deal.
As for being fuzzy, did you read up on the temp qdef? It simply exists only in memory - not in the Nav pane. Practically the same thing, it's just virtual. It dies same as any other memory object (like a recordset) when certain things happen.

If nothing else, you're now aware of it and can use when needed. As I said, if I recall correctly, it even works with tables. Didn't mean to drag this out; was just trying to introduce an option that wouldn't contribute to corruption. Turns out it's not a concern.

Well I appreciate all the constructive criticism as always. The fuzzy part for me simply was that when the database was closed would it remember the switch on open? I don't want to leave the switch in the hands of the end user.

Either way Ill test both approaches and then post my conclusion in a couple weeks or so after Ive had more time to see both in action.

 

[Micron]

when the database was closed would it remember the switch on open

No. I thought you were handling/storing that "last" value then determining what to do in code. My point was all about the frequent altering of a query's sql property, which I guess we've established, isn't a concern. At this point, between the multiple replies and helping out elsewhere, I guess I've forgotten what it is you're doing/not doing in that regard. I might just have a "settings" table and switch the value there and using DLookup to see what it is when appropriate, then make the choice in code, updating the table each time the switch is made.