Search results

If you exceed the number of allowable controls, it suggest you have a major schema design error.

You are asking for trouble. Get off WiFi as soon as possible. It is just not viable with Access except with a server-based back end, i.e., something other than an MDB/ACCDB file.

It also eliminates 90% of the advantages of Access as a development environment.

That indicates an incomplete design. That is, if erroneous data can be entered via a "fat finger," it means your app is not adequately validating input. There are several levels to that: 1. referential integrity 2. field-level validation rules 3. judicious choice of the controls used to edit...

Well, you just revealed the key piece of information: you have a wireless LAN. You can't use Access across a wireless LAN. You can't do a direct synch across a wireless LAN safely. You need to set up a Terminal Server and run the app remotely. That is the only workable solution I can see.

I just replied in the original thread on this. Try completely deleting your table links and relinking from scratch.

Have you deleted the table links and recreated them since you replicated the back end? If not, do so, because the links store metadata about the target table that doesn't necessarily get updated when you update the connect string alone.

If you've looked for the code and can't find it, just say so, and I'll post it the bazillionth and first time.

You're the one who brought up the issue of code, not me, so if there's an ego problem, it isn't mine! I have nothing to say about any of your comments. You clearly aren't equipped to be making recommendations on the subject of Jet replication, because you had bad experiences 10 years ago...

For the scenario described by the original poster here, it *is* easy. You can do direct synchs and it's perfectly safe because it's across a wired LAN. The amount of code to implement it is about 10 lines. It's fast, it's easy to set up, and it will be reliable. It's only when you start trying...

I think Banana has confused the discussion by failing to use the correct terminology. What he's talking about is an ADO disconnected recordset, and the value of it is that it is not connected back to a table or some other data source (a text file, and XML file, a spreadsheet, etc.) -- it can be...

I've posted the code to do the job about a bazillion times in various forums on Usenet and here. Where are you looking? Have you gone to the Jet Replication Wiki and reviewed all the resources identified there as the best starting points? If not, do so, and then ask questions. Otherwise...

The scenario you describe is the ideal situation for the simplest and easiest form of replication, and I'd highly recommend it. When you have disconnected users who need the data in the field, having a local replica to edit is ideal. Then it is very easy to set up direct synchs when the laptop...

To pkstormy: I don't need to post any code. You can simply Google my name and you'll find literally thousands of posts in Access forums going back to 1996 that include lots of code. You could also check my profile and go to my website and find code on my Access page. And you might find the...

In regard to Seek: It's Jet-specific, so never a good idea to use it, since it won't work with any other database engine. Secondly, the circumstances in which you need to jump around a recordset a large number of times and need the performance benefit of Seek over FindFirst are very, very...

You seemed to have figured out the issue of splitting and not using replication to push out changes to your front end. I see only one remaining question, and that's the table-type recordset question. Dynaset is the PREFERRED recordset type, and is what you should have been using even with local...

You mistake autonumber PKs for meaningful data. They are metadata, useful in the background, and if you care what the values are, you really don't understand their purpose. So, this is *your* problem, not Jet replication's problem. Er, what? Do you mean a dropped connection during a direct...

There is no reason to avoid replication if you use it properly. Too often, though, people try to use it without understanding the basics. This is the source of most problems, i.e., trying to do a direct synch across an unreliable connection. The only place I consider it essential these days is...

I don't understand this statement. A "back end" has nothing but data tables in it. A "front end" has forms/reports/modules/etc, and no actual tables, only links to the tables in the back end. Only the back end MDB should ever be replicated, and doing so will have no effect whatsoever on a...

I thought only your back end was replicated? Have you compacted your front end? It's important to do so whenever you make structural changes to your back end, replicated or not. Likely you have compiled query plans that have been invalidated by your changes to the back end and that's what's...