Search results

Fair enough, if you're limiting it to combo boxes and listboxes. For all other control types, not so much (maybe option groups are the same, but they have multiple OnClick events so AfterUpdate of the main option group is the obvious one). I think, though, that given that they have the same...

I you're using MDB format for your back end, Jet Replication is a very fine option, assuming you'll be synchronizing across a wired LAN upon return to the office. Now, replication is not without its problems, so you'd likely want to review what you can learn at the Jet Replication Wiki...

Well, the OnClick() event can fire for actions that don't update the values in the listbox. Since you don't care about any events that don't update the listbox, AfterUpdate() is the correct event.

Compared to the other alternatives it is quite likely to be cost effective. Upsizing to SQL Server, or rewriting for ASP, or using Jet replication properly and safely is going to be vastly more expensive and introduce all sorts of places where things can break.

No one with any sense ever has multiple users opening a single front-end application database, so that can't be it.

Why not? Windows Terminal Server is included by default in all versions of Windows Server starting with Windows 2000, so if you have a Windows server, you need do nothing but buy the CALs for Terminal Server access and make sure you've got sufficient bandwidth and RAM for supporting the number...

This code is awfully convoluted: Private Sub Form_BeforeUpdate(Cancel As Integer) denyflag = TempVars("denyflag") If denyflag = True Then Cancel = False Else Cancel = True End If End Sub This code is exactly equivalent: Private Sub Form_BeforeUpdate(Cancel As Integer)...

Why the listbox's Click() event instead of the AfterUpdate()? Seems to me that is the better event.

In a situation with two fixed offices, Windows Terminal Server is by far the easiest way to deploy an Access app. Replication over a WAN requires Internet or indirect replication, which is complex to implement and requires lots of care and feeding to keep running reliably. It works very well...

I asked this on SuperUser.com: Are you switching to design mode with the Access UI or in code? If the latter, I question why there's ever a need in a production app to do so. If the former, why do you need the variables to survive the switch?

Setting ALLOW ZLS to YES is problematic in that you can no longer just check for Is Null to find empty fields -- you have to check for Is Null or ="". It would be better to make sure that your appends and updates convert any ZLS to a Null.

This is gibberish. DoCmd.SetWarnings does not execute a SQL DML statement. Using .Execute DoCmd.SetWarnings would have no effect at all, so you must be using DoCmd.RunSQL. In that case, if you use DoCmd.SetWarnings FALSE, your SQL will not execute at all, as it's invalid in the first place...

For me, your responses on this subject have basically poisoned the reputation of the username "genesis" on this site. I don't know if you have other nicknames, but I do know that I already had very little patience for you, as you seem to be unable to word your own questions comprehensibly and...

But then the password is embedded in your VBA code. This is only a mild improvement. Sure, the MDE strips out the VBA code and leaves only the p-code, but strings like a password are still there. And my understanding is that the A2007 database password's encryption is still pretty easy to...

Databases passwords have no value whatsoever. They are a much more "fake" form of security than ULS ever was. That they use stronger encryption still does not remove the problems associated with them. What good is a password that has to be embeded in your table links or provided to all the...

The first answer you got was actually correct, but it wasn't very helpfully worded. An appropriate response from you to it might have been something like: "Sorry, but I'm just not seeing the missing space. Can you point it out to me, please?" You could have thrown in a little self-deprecating...

In case you didn't get the point of "you're missing a space", the place you are missing it is between the end of the FROM clause and the beginning of the WHERE clause: insertinto = "INSERT INTO Table1 ( ID, Fn, Mn ) IN 'D:\rommelfiles\Database2.accdb' " _ & "SELECT Table1.ID, Table1.Fn...

I didn't read through to the end of #20, either. It rambled too much without any clear point, so I bailed on it. The lesson, I think is: 1. get to the point. 2. don't offer side observations that don't contribute to #1. Now, I'm one who makes huge long posts sometimes, but I try to break...

I haven't studied the thread in detail, but it seems to me that you asked the wrong question. I may simply be skimming too fast, but it seems you need to reconnect to multiple back ends (for which I have a ready-made utility already available that's been in production use for over 8 years...

I'm not sure if it's what you're looking for, but my Reconnect utility might be exactly what you're looking for: http://dfenton.com/DFA/download/Access/Reconnect.html Because almost all of my apps have a back-end data file and a tmp.mdb stored on the user workstation (not always in the same...