Search results

Then I don't know what the dispute is. Nobody has suggested *not* using form-based datasheets, just that one should not expect them to be like Excel.

I'm not sure who you're trying to provoke, but there are a number of issues here: 1. expecting the UI in Access to behave like a spreadsheet -- not reasonable. 2. using table datasheets instead of form datasheets -- a reasonable rookie mistake, but anyone who has tried it should quickly...

Only if Excel is your model for how it should behave, and I think a spreadsheet is a very poor model for designing the user interface for data tables.

On the question of SHOULD, I say it's my duty to steer someone away from what is, in my opinion, a bad idea. I would almost never say "you shouldn't do that" and offer no explanation -- I'd almost always explain what the downsides are of the direction being recommended against. In many cases...

If you have no network connection at all, none of these usual options are available (in descending order of preference, in my opinion): 1. host the app on a Windows Terminal Server available to all (requires full-time Internet connection). 2. deploy using Sharepoint (requires ability to...

Because of various issues with the interrelationships between the delete events, I tend to never rely on the default Access interface for deleting records, except when I don't need to do anything special. In the case you're in, I'd turn off the subform's AllowDeletes property, and create a...

I'd say your only option is remote desktop. Keep in mind, though, that certain things are different on iPad. For instance, one of the main reasons Flash movies cannot be ported to iPad is that so many of the Flash movie players depend on hover for revealing the player controls. Multi-touch...

I don't know what the future of Access is in terms of programmability, but it seems pretty clear to me that Microsoft is currently putting its resources into the macro builder so that limited scriptability is possible. That allows them to convert the macros to something that is guaranteed to...

I don't see why. .NET is not some magical solution to every problem. That said, an Access web app delivered through Sharepoint Access Services is, in fact, converted to .NET XAML forms (or whatever object XAML represents), according to a post today by Albert Kallal in another forum. So, you've...

If they won't allow WTS and RDP, then they aren't going to allow you to install the components necessary to use Jet replication. You probably know this better than anyone else, but the "security" excuse for not using WTS and RDP is complete hogwash. It's actually more secure (and more easily...

I don't think this is a good idea. You're just trading one set of problems for another. As someone who has been creating and maintaining replicated apps since 1997, I would never do that, but would instead use Windows Terminal Server to host the app and users on the WAN would use Remote Desktop...

I think you're wanting Access web apps to be something they are not. An Access web app has a limited set of functionality because web applications have a limited set of functionality. Arbitrary VBA code can't be guaranteed to be convertible to something that can run in a web browser, so it...

Controls do NOT have recordsources -- only forms and reports do. If the error message is reporting a problem with your form's recordsource, then LOOK AT THE FORM'S RECORDSOURCE. Perhaps when you thought you were renaming a control, you were actually in the form's property sheet and changed the...

Lose the table name. You need only the field name. And, for what it's worth, the Link properties are not limited to fields. They can be any expression or control whose value provides the right data to make the link.

There is no problem running multiple versions of Access on the same computer. But you could encounter problems if you run them simultaneously. That is, I have A97, A2000, A2003 and A2007 on this PC. A97 doesn't interfere with the others because it doesn't use the MSI, but as long as I run any of...

You colleague is giving advice that falls apart if you give it any thought at all. If you query the ODBC database directly, it returns the results, say 1,000,000 records. If you copy the data for querying, you have to pull down the 1,000,000 records and only then query them for what you want...

1. Global Variables are generally bad programming precisely because they are global -- i.e., not appropriately limited in scope. The downside of that is that they can be changed globally and so you don't really know what's in them when you call them (they could have been changed somewhere else...

I would dissent from that article's approach -- relying on public variables is simply a terrible, terrible way to do this. Anything that relies on global variables of any form is, in my opinion, likely an erroneous approach to the problem.

For supporting multiple sites, I'd suggest hosting the app on Windows Terminal Server/Citrix, or using Sharepoint. Jet Replication is simply not the best choice for that scenario any longer (while from c. 1997 to 2001 or so, it was the absolutely best solution in terms of ROI).

If the network is ludicrously slow, that may indicate that it's also completley unacceptable for using direct synchronization, which is dangerous except on a reliable and reasonably fast network (at least 10mbps). Also, if it's WiFi, forget it. You can't use direct replication on a wireless...