Problems with Indices of Magento. - magento-1.6

I made an indexing Indices at my store, and yet they are still with the status "processing".
Even I have the reindexed via ssh, the status is still "processing".
And due to this, new registered products are not being displayed in my store.
Have googled but have not found solution for this, someone has been there, someone with some advice on how to solve?

I solved the problem by deleting the files from var/locks folder

Related

File Addition and Synchronization issues in RavenFS

I am having a very hard time making RavenFS behave properly and was hoping that I could get some help.
I'm running into two separate issues, one where uploading files to the ravenfs while using an embedded db inside a service causes ravendb to fall over, and the other where synchronizing two instances setup in the same way makes the destination server fall over.
I have tried to do my best in documenting this... Code and steps to reproduce these issues are located here (https://github.com/punkcoder/RavenFSFileUploadAndSyncIssue), and video is located here (https://youtu.be/fZEvJo_UVpc). I tried looking for these issues in the issue tracker and didn't find something directly that looked like it related, but I may have missed something.
Solution for this problem was to remove Raven from the project and replace it with MongoDB. Binary storage in Mongo can be done on the record without issue.

Intermittent errors with new code release to existing Mojolicious app

I'm having a problem with an existing Mojolicous app. I have added some new routes, views, controllers, and models, and am returning database results to view using Rose::DB::Object ORM.
I updated the production version today with code that had been working great on Morbo. But, on apache2/plack/psgi mod_perl config the new Models are only returning the queries about 1 in 5 sometimes 1 in 10 times.
I've eliminated a number of variables, like I can query the database directly and get my results no problem. Older Model's and their queries always work.
It appears that only this new functionality is intermittent. I have narrowed requests to only one server and have restarted apache. But, am now at the point that I don't understand why the issue is persisting.
I think this is some kind of mod_perl wonky behavior, but don't know why an apache restart doesn't fix it.
Any help or ideas would be awesome.
I did finally resolve this and it turned out to be something simple. I was missing the use statement for my controller in my main application script. The script where I setup the routes. I'm not sure I understand why it was working intermittently in production and working all the time in development. But, once I added:
use TheApp::Controller::Tags; in the main app pm it worked consistently.
In retrospect it feels like I should have figured it out sooner, but the fact that it worked part of the time led me down the wrong path. Hopefully this will help someone else sometime.

Chrome OS bug - file select dialog (for uploads) 'stuck'

The best way to sum up the issue would be with a screenshot, but unfortunately my screenshots auto-save to downloads and so I can't upload them. What's happening is that when I enter the 'file select' dialog in trying to upload a file, it's automatically in the 'drive' folder and won't move to any other folder. I've tried restarting and resetting my machine, tried the upload process on a bunch of different platforms, tried using the other user account on my machine, tried updating my software, but none of these have made any difference. I can get into my downloads folder and open files from it fine outside of this context, and I can workaround by using the drag-and-drop to upload on platforms which have this feature, but otherwise I'm stuck.
I've googled extensively to see if anyone else is having this issue and have found this thread: https://productforums.google.com/forum/#!topic/chromebook-central/d7g9EEDsr8w but there's no helpful solution there (recommended a powerwash but the asker has already done this several times). I've also tried to find a solution with the help of my (programmer) employer, but no luck so he recommended asking here. It seems like it wouldn't be a hardware issue when I can still access the folder outside of this specific function, but if it were a problem with the running system it seems it would be happening across the board and therefore show up more in a google? If anyone has any suggestions I'd be very grateful as it's getting quite tiresome having to drag and drop things into Facebook messages to get them uploaded! The machine is less than a year old so if I can't find any solution I'll see about getting it replaced under warranty. Thanks in advance for any help, and please let me know if there's any key info I've left out!
Machine: Samsung Chromebook XE303C12
OS: Version 38.0.2125.110

how can I get rid off duplicate defect(accuwork) on AccuRev

I am seeing there are duplicate issues with one defect within a minute. why this is happening and how can i get rid off this? any help will be appreciated.
There is no way to delete/remove an issue from AccuWork. You will need to close the duplicate issues that have been created and just keep the original open.
As for why this is happening, you could look at the history of these issues and see who is creating them. I am going to guess you have an automated process or an AccuBridge solution in place which creates the issues.
Check for more than one perl process on the machine running accubridge. That would be an indicator that you have multiple instances of the bridge running.

Migrations don't run on hosting

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.