sgtaz
01-12-2007, 12:41 AM
When I try to edit a macro in my replicated database, I get an error message that says "invalid data format" and I cannot make any changes to the code. Is there a way I can edit the code?
|
View Full Version : Editing Macros in replicated DB sgtaz 01-12-2007, 12:41 AM When I try to edit a macro in my replicated database, I get an error message that says "invalid data format" and I cannot make any changes to the code. Is there a way I can edit the code? boblarson 01-15-2007, 12:14 PM You can't edit any objects in a replicate of the design master. All changes have to occur in the design master and then be propogated to the replicate via synching. sgtaz 01-19-2007, 06:13 PM thank you, but I am working in the design master, and when I make changes, I get this error. boblarson 01-19-2007, 07:05 PM It could then be something within your macro. Can you post the database here? Or at least a stripped down version? Or at the very least, a few screen shots of the error message AND the macro. sgtaz 01-23-2007, 12:43 AM in the word doc are the error message and printscreen of the section of code. also attached is a zipped copy of the DB. Thank you for your help. boblarson 02-05-2007, 08:04 PM thank you, but I am working in the design master, and when I make changes, I get this error. You attached a replica and not a design master. The module 1 has something seriously wrong with it. Remove it and start over on it. Once removed (and working in the design master, which I had to create by using "recover design master." The other thing I noticed is that you have DLookup code to lookup an authorized user, but there is not table called "Authorized ID" which is supposed to be the underlying table in the query "authorizedassociates" which you are referencing in the DLookup (in the form's on open event). I'd say start with those and then we can go from there. Sorry I didn't get back to you but somehow I didn't see the updated post with the database and screenshot. dfenton 05-22-2007, 05:14 PM You attached a replica and not a design master. Um, no he did not. The problem is that it's only a DM in its original location, on his computer. For you to work with it, you'll have to make it the DM. This is to be expected with Replication -- it's the way it works. A DM only remains a DM as long as it has the original name and is on the original computer in the original location. Replicating front ends is wrong, anyway -- it just doesn't work reliably. Besides, conceptually, it makes no sense, since you don't need to exchange any kind of data (i.e., it's a one-way operation). It's much easier and much less problem-prone to simply copy a new front end over top of the old one. I checked out your database and it is riddled with major problems. First off, in frmCalendar, you have code that refers to a control (gtxt something) that doesn't exist. Thus, the code can't compile. After I decompiled the code and put a control on the form with that name, the code compiled. But the startup form is somehow badly corrupted and every time it opens, Access just crashes completely -- it vanishes. This is exactly the kind of thing that results from replicating a front end -- weird unfixable errors like this. I would import everything that I can into an unreplicated MDB and go from there. Otherwise, I don't think your project is recoverable. I wouldn't waste time on it as long as it's replicated. Oh, of course -- you need to split it into front end (forms/reports/etc.) and back end (tables only), and link the front end to the back end tables. If you need to share the data, then you can make it replicated. Otherwise, you don't need replication at all. -- David W. Fenton David Fenton Associates http://dfenton.com/DFA/ boblarson 05-22-2007, 05:17 PM Um, no he did not. The problem is that it's only a DM in its original location, on his computer. For you to work with it, you'll have to make it the DM. This is to be expected with Replication -- it's the way it works. A DM only remains a DM as long as it has the original name and is on the original computer in the original location. Replicating front ends is wrong, anyway -- it just doesn't work reliably. Besides, conceptually, it makes no sense, since you don't need to exchange any kind of data (i.e., it's a one-way operation). It's much easier and much less problem-prone to simply copy a new front end over top of the old one. -- David W. Fenton David Fenton Associates http://dfenton.com/DFA/ I worked with a design master of a replicated database (back-end) for 4 years and I transferred it all over to a desktop to a laptop to my home desktop and never once did it need me to change it to a design master. dfenton 05-23-2007, 02:23 PM I worked with a design master of a replicated database (back-end) for 4 years and I transferred it all over to a desktop to a laptop to my home desktop and never once did it need me to change it to a design master. That's very interesting. How did you manage it? Any time I move a DM to a different location it opens as a replica and has a new ReplicaID. I've tried this in A97, A2K and A2K2 (the Access versions I have installed on my workstation). The only way I know to avoid losing DM status would be to have your home computer have the same name and same directory structure so that Access had no idea that it was not in its original location. Are you doing something special here? Or is there some special circumstance I'm unaware of? Can you explain the steps you use to take the DM home with you and work on it and return to the office? -- David W. Fenton David Fenton Associates http://dfenton.com/DFA/ boblarson 05-23-2007, 02:30 PM The only way I know to avoid losing DM status would be to have your home computer have the same name and same directory structure so that Access had no idea that it was not in its original location. Actually, now that I think about it, I think you hit on it with this. dfenton 05-24-2007, 09:14 AM Actually, now that I think about it, I think you hit on it with this. Well, let me say that I think that's attempting to trick Jet Replication and I would say that is a very bad idea. I'm never in a position to be able to do it, anyway, as I always need to connect my work computer to the networks on the other end, and if I gave my computer the same name, there'd be a NETBIOS name conflict on the network as soon as I connected to the network and it just wouldn't work. If you never connect your home computer to the other network at the same time the other computer is on and connected to that network, I guess that wouldn't be a danger. But I really wouldn't advise it. It's really an effort to subvert the way Jet Replication was designed to work. And it's so incredibly uinnecessary these days with Windows Terminal Server and Remote Desktop being so incredibly easy. And it would only work if you only had one client to work with. I'm an independent consultant, and I'd have to change my computer name each time I switched from one replicated client to another. It's much, much easier to edit the DM in place, via remote control (I use Windows Terminal Server for clients with servers, and VNC for clients with peer-to-peer networks). -- David W. Fenton David Fenton Associates http://dfenton.com/DFA/ |