I ended up corrupting my database to where every time I attempt to open it, I get error 3022, "changes you requested to the table were not successful because they would create duplicate values in the index."
Recovery of the file does not seem possible and my previous back up is a month ago. I have been able to extract everything but the Modules, which is what I need to recover the most. None of the standard ways I have found work because they require the ability to open the database (For example, trying to set it as a VBA reference still give the same error.)
Is there any way to get the modules or code out of the file without opening it?
Edit:
Was finally able to get access to the file. Using DBEngine.CompactDatabase it was able to do a compact and repair. The issue has boiled down to the "MSysAccessStorage" table is corrupt, and says "Id is not an index in this table". I know have access to everything, except the modules, which I can't open without the MSysAccessStorage working.
I'm going to keep poking at it but I'm not sure what options I have for fixing a system table. Any ideas would be helpful.
Unfortunately, the Visual Basic for Applications project has been corrupted. The original database doesn't even have any VBProjects when listing a count. I'm going to call this one a lost cause. Thanks everyone that tried to help.
Related
I have an ETL routine in PENTAHO and I'm migrating to APACHE HOP.
But I came across a situation, the HOP step/plugin "Microsoft Excel Input" cannot read the data before I open the excel file and click confirm Add Confidentiality Label.
In PENTAHO PDI this problem does not occur, does anyone have any tips?
IMG 1
After clicking and adding a confidentiality label like "public" for example and saving and closing the file, the process works perfectly.
Note: This only happens with some files.
This sounds like a problem that will not have a clear and direct answer and will require some changes in the code.
The code for Apache Hop is managed on Github.
You can create an issue there and one of the developers will help you get this sorted out. When creating a ticket please be as specific as you can be and add a sample, that will improve the chances of getting a fix on short notice.
I am using PHPMYADMIN from SiteGround CPanel.
Story: I had Cloudflare setup for a php platform, I then realised it was causing issues so I removed it. The issue I'm left with is that half of my site is still running of (https://www.example.com).
What I have done so far: In the config files of my script I have already set it so that it runs through https alone.
What I want to achieve: I noticed in the database that there are some fields that are running through the www. I want to execute a command that will automatically find anything with my old domain (https://www.example.com) and replace it with (https://example.com). I noticed that the fields are not all appearing from a single column/file, it is all over the place, so a field&replace overall should fix the issue.
I would appecaite any help. Since it is database I don't wish to try out random things from different websites provding their feedback. I was recommended to use this website for assistance (if possible).
Thank you in advance.
Probably the most straightforward and quickest way, is to simply take a dump of the entire database, open the sql dump file in some text editor, and then do a text replace from [old url] to [new url]. Then import the dump file back to the database. This should work just fine and avoid the headache of uncertainty and risk over doing a write operation on the entire database's tables via some db query.
I have an MS Access split database and I'm trying to get it to work with the backend on a new, more secure drive on our network. I've used a UNC path for the backend location.
This database has been running without problem on another drive which is totally public to everyone in the company (~4k people, not secure) for about a year. We have a generic account for users to access the database throughout our factory and haven't encountered this problem before I tried to switch it to the new drive. I've contacted our IT department and they've given myself and all my user's accounts read/write access to the drive, but only I can run it.
Other user accounts get these problems...
All of my forms with objects bound to a table immediately throw a runtime error before even getting to Form_Load.
My userforms will run DLookup functions and execute message boxes but throw a runtime error when they go to execute a query.
I've tried using an 'On Error goto' to try and actually find the problem but it throws a runtime error before that.
I can't think at all what the problem might be. IT have told me I have the same permissions as the other users. Any suggestions on what to do?
In the front end of your DB you may have to change the path which links to the tables. The tables are in the back end of the database, which you have now moved and therefore changed the filepath. the frontend wont find them. You can delete the table links in the front end then use External data > import and Link > Access. In order to re-link the tables using their new filepath. You would then need to redistribute your frontend to the users.
I'm not sure if you have already done this, however, you haven't suggested so in your question. hope this helps, apologies if it was helpless.
I hope you have found an answer to this. I wanted to answer as well, because I had the exact same problem yesterday. It turned out that the location was referring other users back to the folder's shortcut name versus it's full length name (it is called the W drive on my computer and the K drive on theirs). I solved the issue by spelling out the name in full.
I'm using MigratorDotNet to manage Rails-style migrations for my web app. I have a workflow where, if I delete all the tables in the database, I can access an installation view that will run MigratorDotNet and create all the necessary tables.
This works locally. For some reason, when I upload my code to my Arvixe hosting, the migrations just never run. I get this odd error:
There is already an object named 'SchemaInfo' in the database.
This is odd because, prior to running migrations, I manually deleted all the tables in the database (to make sure it wasn't left over from a previous install).
My code essentially boils down to:
new Migrator.Migrator("SqlServer", connectionString.ToString(), migrationsAssembly).MigrateToLastVersion();
I've already verified by logging that the connection string is correct (production/hosting settings), and the assembly is correctly loaded (name and version).
Works locally, but not on Arvixe. How do I troubleshoot this?
This is a dark day.
It turns out (oddly) that the root cause was my hosting company used a schema other than dbo for my database. Because of this, the error message I saw (SchemaInfo already exists) was talking about their table.
My solution, unfortunately, was to rip out MigratorDotNet and go with FluentMigator instead. not only did this solve the problem, but it also gave me a more intelligible error message (one referring to the schema names).
While it doesn't seem possible to auto-set the schema, and while I need to switch the schema on my dev vs. production machine, it's still a solvable problem (and a better API, IMO). I googled, but did not find any way to change the default schema in migratordotnet.
I'm sorry for the issues that you were having. On shared hosting, unfortunately the only way that we may be able to change the schema is manually. If you are still looking for a solution that requires our assistance, please forward your ticket ID to qa .at. arvixe.com as well as arvand .at. arvixe.com and we can look into the best way to resolve this.
Just a little background: I am using Access 2010 to create forms and VBA code in an Access 2003 format database. For some reason, Access 2007 format databases always corrupt on me when I make changes and save them with a particular group of objects, but that's for another discussion.
When writing VBA code in this Access 2003 database, any time my code breaks (via breakpoint or an unhandled error) and I make a correction, Access tells me that it can't save back to the database because another user has it open. However, I am the only user working on the database; this is a local copy of the database and it's sitting on my desktop.
The LDB file can't be deleted because Access is using it. When I first load the database, I see my machine name and "Admin" when opening the LDB in a text or hex editor. After a break, I see that plus a duplicate entry, but this time around "admin" has a lower-case "A."
Closing the database and reopening it fixes the problem but makes it needlessly cumbersome to debug my code. Anyone else encounter this issue and/or have a fix for it?
It might be helpful to know what your code is doing when this happens. Certainly that's not normal behavior. For instance, are you opening another database with New Access.Application? Are you using ADO or DAO to access records in the database with a connection string?
There are no external connections to the database at all.
It may not matter if there are external connections to the database if you are using a connection string to connect to the open database; not sure but that may be seen as an external connection... you may want to use CurrentDB for DAO, or CurrentProject.Connection as your ActiveConnection for any ADO queries.
I am assuming that this problem persists through reboots; but for the sake of argument, try closing out Access and going to the task manager to make sure you have no other instances of MSAccess.exe running. You might even try closing all Office products and/or making sure that Access is the only Office product running. I have seen some weird conflicts between Microsoft Communicator and Outlook; so it's not entirely out of the question for Access to have issues with another MS product.
You may also want to check the size of the database to make sure it's not exceeded 2GB. That causes the infamous "Invalid parameter" error; perhaps it might be causing this as well.
With no other details about how your program works, we may only be able to offer generic advice like this.
I have discovered a way to cause the problem discussed above (and thereby to correct it). Turns out if you create a database object and set it to the current database, you get this problem.
That is,
dim cdb as database
set cdb = currentdb
From this point on, you're cooked.
Instead, figure a way around this by possibly using currentdb directly or not using it at all.
This worked for me.
In your VBA Try checking that all your open Connections to the database are closed. Until the connection is open the LDB fill will be there.
Same symptom of not being able to save form or code mods after application had started. I found a workaround today! In the startup of my first form of the app, I had issued a "DAO.DBEngine.SetOption dbMaxLocksPerFile, 20000". Commenting this statement removed the problem. I did no further testing, but FYI, the DBEngine call was before any reference or attempt to use CurrentDB(). Also the current default on my Access 16 install is 9,500.
I thought I might answer here, since I stumbled upon this question while having a similar issue. Essentially, it boiled down to this: I could either edit forms, VBA, etc. or edit information in the local database (which I'm using as a cache) with currentDB. I also have a backend database, but the locking was clearly on the frontend database.
The solution ended up being weird, but stupidly simple. When the frontend starts up, I have it immediately create a connection to the backend using OpenRecordset (and similarly to you, that backend was still on my own computer for testing purposes). I tried temporarily disabling that code, and suddenly it wasn't an issue anymore. And it turns out, once I call currentDB, I can then call OpenRecordset to open the connection to the backend, and suddenly it isn't a problem anymore.
Tl;Dr: if you're calling OpenRecordset somewhere in your code to connect to a backend, be sure to call something like set db = currentDB beforehand, then everything works. (That is, probably until I publish this answer and Access then decides it doesn't want to anymore).
Why this fixed it is beyond me, someone with more knowledge can maybe answer that.
The solution:
options > current database > click enable -track name auto correct info