Search results

I'm really confused. There's a horizontal scrollbar at the bottom of the relationships window -- doesn't it work? If so, scroll to the right until you can see the table, then drag it as far to the left as possible, then scroll over to the left, and drag it some more. This same thing sometimes...

I would blame compiled p-code mismatches, and would go through a full decompile/compile cycle on both target platforms.

Nothing more to say, Bob -- you covered it -- other than to point to the Jet Replication Wiki: http://dfenton.com/DFA/Replication/

Partial replication is supported, but based on data-based filters that have to respect relational integrity. I don't recommend mucking about with partial replicas. Having all your data in multiple replicas is a great backup when something goes wrong. Instead, I'd filter the data in the front end...

One handy way to do it is to create the buttons on a form and insert them as a subform on all your forms. That's how it's done in the app where these three forms come from: http://dfenton.com/DFA/examples/Activities.gif http://dfenton.com/DFA/examples/assignment.gif...

I had this problem JUST YESTERDAY. You are not going to be happy to hear what's going on. Basically, your VBA project is corrupt and you need to write all your objects out as soon as you can. I'd try using Application.SaveAsText to save all the objects. Likely, they are already too far gone to...

I eventually determined today that the VBA project in my test database was corrupted, so I recreated from scratch, making sure I turned off Name AutoCorrect before I imported anything. I haven't had any issues since then. I suspect this error message is an early harbinger of VBA project corruption.

I've run onto this problem today, too, and don't think I've stamped it out. But perhaps one things is turning of Name AutoCorrect. I was working in a stripped-down sample database to try to isolate an error, and encountered the "isn't enough memory" error in the sample database, one that has...

To export to HTML in code, you open a recordset, walk the records, and output the data from the fields into a string variable with the HTML, then write the string variable to a file. Ask for help on any step in that process.

To me, developing in .NET and using Jet/ACE as a back end is turning everything upside down -- you lose the RAD capabilities of Access while using a fine, but not terribly scalable back end.

I would never use a report layout to export to HTML. Instead I'd do it all in code, based on a recordset.

Is your application split? That is, are tables in one database (back end) and the forms/reports/queries/modules/macros in one file (front end) with links to the back end? If not, now is a good time to fix that. This means you can send your new front end without overwriting the users' data...

Do you need to edit the data on the laptop disconnected from the network? If not, you don't need replication -- you just need to split the app. Your app should be split no matter what, replication or not.

THIS IS WRONG. Access 2007 and Access 2010 fully support support Jet replication for MDBs. It is only the ACCDB format that doesn't support replication. Please educate yourself about these issues before mouthing off about things you don't understand.

The point of my asking about the memo field is simply that a corrupt memo field pointer can cause symptoms similar to what you've described. Another possible cause is a corrupted index.

This is a long thread and I skimmed through it quickly, but is there a memo field in the problematic table?

One thing, if the .NoMatch is true, check if the record is dirty and save it before navigating via bookmark. This forces any errors that might occur in the saving of the record to happen before record departure. Skipping that step can result in data loss.

It seems to me that if if the LD is, say, 6, and there are 12 characters, that would be 50%. But you can't just divide the two. You have to subtract the LD, then use the remaining number divided by the length. Something like: lngLD = 6 lngLength = 12 Percent = (lngLength - lngLD) /...

Easier for whom? Maybe easier for the developer, but as you're finding out, it's obviously not easier for the users. Forms are for editing/viewing data. Reports are for printing. If you maintain that distinction strictly, then you'll enounter fewer problems. But, it's true, it WILL be more...

Reports are for printing. Forms are for editing/viewing. Forms should not be used for printing.