Search results

Is DoCmd.RunCommand acCmdPasteAsHyperlink what you want? It's not clear from your question what the context is.

I would say the idea of using empty tables is crazy. Just use the SQL Server data directly, with ODBC linked tables. All of my apps have two back ends, the shared back end tables, and a local tmp.mdb for the temp tables that is stored in the same folder as the user's front end. This seems to me...

VBA is not interpreted at runtime -- it's precompiled to p-code. This makes it substantially more efficient than pure interpreted languages.

I believe that tax rates in general need some form of storage. I don't store the rate, but the result of the calculation in each invoice item. There are actually two reasons for this: 1. as you've found, tax rates change, so you can't link them to a tax rate table without complex logic...

Behind the scenes, they are actually stored in the usual way, with a join table and a lookup table. This is all hidden from the user, though, and is harder to manipulate for someone with programming chops than if the programmer just implemented it explicitly. Sharepoint compatibility was the...

There are plenty of methods that require no code. Here's one that is incredibly good: http://www.autofeupdater.com/ Or you could write batch files to do the job, of vbScript, but of course, those would be executing code, just not as part of your app. Replication is simply not a viable...

If all you're doing is running SQL, I'd suggest doing the whole thing in vbScript using Jet, and save the overhead (and problems) of launching Access (which will work reliably only if the user account it is runing under is logged on).

The weird thing about them is that they actually *are* relational, but the whole thing is hidden from you. And it's quite difficult to work with them in code (or it seems so to me), as you can interact with them only through recordsets, unlike any other data type in Jet/ACE. Once you get to that...

Multivalued fields are for end users and for Sharepoint compatibility. No one who can actually program in Access should use them. It would be nice, though, if MS would add the checkbox functionality that you get with the MV lists to its standard combo/listbox controls.

How, exactly, would replication help with the stated problem? Seems to me it would cause you to lose the record of what has been changed so you couldn't create a report. It's not clear to me what the original poster is trying to accomplish. The answers to the original question have assumed that...

It's completely idiotic to do something you know is going to fail at some point when it's so incredibly easy to avoid the issue. Indeed, it's *much* easier to not use replication for distributing front end changes, since you don't have to use code to distribute your changes (which you must do if...

Yes, of course it's possible to do one-way synchs, but that's not what replication is designed for. In a split application (the only kind there should ever be), you push out updates by replacing the existing front end with a new front end -- no need for replication. In an unsplit app, you've...

Can you edit your question putting the CODE tags around your code, so the indentation is clear? There appear to me to be a lot of redundancies in your code, but it's not clear without it being formatted appropriately. To format as code, put the word CODE in all caps inside square brackets ([])...

In addition to Bob Larson's comment about the danger of losing your project from replicating your front end, let me add that if you give any thought at all to what replication is about, you'll realize that you *don't* want to use it to push out front-end databases. Replication is a two-way...

Keep in mind that editing the same table in two different forms can lead to write conflicts.

It may come as a shock to you, but Access doesn't execute any of your SQL -- it hands it off to Jet/ACE, or to whetever other interface you're using to a different database engine (via passthrough over ODBC/Jet/ACE, or ODBCDirect, or ADO/OLEDB).

Of course it is! You just have to use a back end whose SQL dialect supports it. Jet/ACE SQL does not, but you aren't limited to Jet/ACE when using Access.

Very often, there's not damage to data at all, but this is all outside Jet's control, so I don't see you could blame Jet for giving up! Quote: Well, in the multi-user scenario, if something gets written anyway, without the client Jet instance being able to read the LDB and figuring out...

Jet was written to protect your data. It gives up when it can't insure consistent data gets written, and it does it as soon as the connection is suspect. That's a GOOD THING. In a single-user scenario, that could work, but in a multi-user scenario, it would be a recipe for disaster. I think...

Novell switched to TCP/IP for its networking stack over 10 years ago, and NETBIOS is only going to be in use in peer-to-peer networks. I'm a huge fan of NETBIOS, actually -- it's incredibly fast and efficient -- but it's non-routable, so not really usable on a network of any size. The reason...