I am using MySQL Cluster Auto-Installer. I click the next button while keeping the default configurations. But finally when i click Deploy and start cluster it will give me the following error.
I cant find any information regarding this message in the web.
#dennypanther, It's always in the config dir such as: /usr/local/mysql/mysql-cluster/ and It´s called "ndb_49_cluster.log".
In addition, maybe you could find it within a folder named with the same node id, for example: /usr/local/mysql/mysql-cluster/49/.
It depends how you configure it in the installation process.
I guess you resolved this problem a long time ago, however I try to help you as much as posible.
This looks like a bug fixed in recent 7.5 release of MySQL Cluster.
I did the bug fix myself, there was an issue with
not handling Windows character set properly that
made the start of the management server fail.
Fixed by handling also Windows character set
in messages from OS. Don't recall exact version
it was fixed in, but definitely fix is in latest
7.5.
Related
I have connected to my work database via DBeaver. Recently colleague told me about a procedure that lets me check newly added entities through our front-end.
And I can't find it in the list of procedures, nor using this query:
SHOW PROCEDURE STATUS WHERE Name LIKE '%name%'
I have the same connection settings as my colleague's, same user, etc, but he uses DbForge and I use DBeaver, cause at some point of time DbForge began having too much restrictions for free version (I wasn't simply able to execute queries), and the older version my colleague gave me didn't install in Windows 11.
So, I'm thinking may be there's some settings in the DBeaver that hide certain stored procedures, or I need to adjust connection settings.
Does anyone has clue on this?
Or may be someone could suggest some alternative to DbForge, which allows to execute queries in the free version and to set colors to connections (I find that thing convenient), and possibly doesn't have this problem, may be because of being more MySQl-oriented.
Thanks in advance!
I've tried to open connection settings and check out the additional parameters there, but can't seem to notice anything relevant.
Ok, seems like there was misunderstanding between me and my colleague, and he actually meant some another DB Server, but with same User/Password combination. Thanks for the comments, that also helped in finding the cause. I really did install MySQL Workbench, saw the same picture in there, and started wondering what else it could be and reading our communication again.
My mistake) The question is no longer actual.
I use TYPO3 7.6.X with news extension.
I have a category "Events" that contains many Newsitems.
When I add a newsitem in this category "Events" it take a lot of time.
I did a System environment check with the install tools and all is Ok (green).
Also, nothing special in the Chrome network Tool.
What can it be like cause ?
There is likely a significant impact from reference indexing, especially if you use IRRE relations from within your records, or use heavily populated references.
You can use this extension that I created as a way to defer reference indexing from occurring on-the-fly to being processed as a queue (by a cronjob).
https://github.com/NamelessCoder/asynchronous_reference_indexing
For a TYPO3 7.6 compatible version you have to download/require the 1.2.0 version which is the last one to support 7.6:
https://github.com/NamelessCoder/asynchronous_reference_indexing/tree/1.2.0
If you composer require namelesscoder/asynchronous-reference-indexing and use composer to install TYPO3 you would get the right version automatically but for manual installs you have to select it yourself.
The "Background" section of the README.md explains a bit more in detail about why reference indexing sometimes becomes a very narrow bottleneck for performance in backend.
It is a bit strange to give you a proper answer but let me try to explain. Probably to reason behind the slow process could be:
Server response issue
TYPO3 installation or Extension issue.
To determine the issue, you can follow the checklist below:
Check server configuration (You can connect with your server administrator)
Enable the Apache server log (php.ini file).
Update TYPO3 version to the latest version.
Update extension to the latest version.
Enable TYPO3 error & deprecation reporting (Dir: typo3conf/ext/LocalConfiguration.php).
Check the system log and Apache log to ensure what's wrong going on.
Hope this will help you!
Bit of a back story, I was using MySQL Server 5.X on an old server. Retired server and migrated all data to a new server with MySQL 8.0.11 (now 8.0.12) installed. Used Legacy authentication to reduce issues.
This seemed to work and all my programs open/ran as expected. I've been editing them and publishing without any issues as well, however in that time I have not had any reason to change any of the data sources.
I've gone to change the data source today though and can not get it to work for the life of me.
If I try and make any changes I get the error "Configure TableAdapter tbl_users failed. Specified cast is not valid.". Obviously the table name varies and this happens regardless of which table (even trying to add a new table that I've just created).
It seems to work though, but on closer inspection, the delete and update commands are not created which means if I try and run the application I just get errors.
I've currently got:
Visual Studio 2015
MySQL Connector Net 6.9.8
MySQL for Visual Studio 1.2.7
Thanks in advance for any help/ideas.
#A Tyler. I suggest trying to update the MySQL for Visual Studio and MySQL connector to the newest versions. Have you tried that?
I think this issue is somehow related with the one described here.
https://bugs.mysql.com/bug.php?id=31338
This bug dates back to version 5.1 of the connector and VS 2005... should have been fixed right now, but the symptoms are very similar.
Maybe you found any other solution?
Update:
I 'slept' with the problem and found a workaround on the next day. This does not really solve the issue but made it possible to continue with the project.
I went to the 'properties' window of a table adapter and manually edited select and update commands there. It caused the table adapter to reflect these changes and I could use the new table field in my program. For me, this is good enough.
The database that I am working on (in MS-Access XP) seems to have become corrupted somehow. It no longer supports any events - clicks, change, update events, nothing seems to work. This is the error that I get:
The expression On Change you entered as the event property setting produced the following error: Object or class does not support the set of events.
What can I do to make events start working again? I have tried Tools->Database Utilities->Compact and Repair Database..., but it didn't help at all. Also, it hasn't been like this the whole time - events were originally working, but now nothing works, not even the auto-generated command buttons.
Compact and repair generally won't solve problems that happens in objects other than tables and indexes. Importing usually fixes those but maybe try a decompile and then an import. Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times
I encountered the same problem once and documented my trouble shooting steps here. The expression On Click you entered ...
Also see Corrupt Objects within a Corrupt Microsoft Access MDB
Long discussion summarized.
One page that might have a solution that might help is Errors using multiple versions of Access under Vista/Windows 7 This is basically a permissions problem into the registry.
Another suggestion is to to repair the Office 2003 installation in control panel. A2003 then reverts to using Version 11 of the library, but only until A2007 is used again, then the problem reappears.
The original poster stated "Okay, after a few restarts, it seems that removing the 2007 runtime did fix the problem for me. "
Tony alluded to this in his long string of comments, but this sounds exactly like the dueling Access registration problem. I hadn't used A2007 until recently (I had the runtime installed to test if a database developed in A2003 could be deployed under it -- it could -- but hadn't used it since that testing was completely), and when I run A2007 after I've been using A2003, it has to reconfigure itself. The other day, something went wrong during the A2003 reconfiguration (after having last run A2007) and I got errors similar to yours. Running A2007 (to re-register everything as A2007) and then running A2003 (to re-register everything as A2003) fixed the problem.
The key is that when the re-registration fails, Access doesn't necessarily know it the next time it runs, so you end up running in an environment that is partly registered for A2003 and partly for A2007. The way to restore it is to run the other version of Access. That is, if A2003 is launching without the reconfiguration notice, then close it down and run A2007 so it reconfigures itself and re-registers itself as the real Access. Then when you run A2003 next, it will re-register itself as the authoritative version of Access and your A2003 app should have all of its references in proper shape.
Yes, this is very annoying.
And time-consuming.
I don't know why MS seems to think this is something that doesn't need to be fixed. While I know they don't give a rat's ass about developers who need to run A2003 and A2007 side by side, there are plenty of end users who might have an A2007 runtime app installed but also have A2003 installed as part of their base Office installation.
This has been going on forever, so I doubt it will ever be fixed.
I have encountered the same problems many times in Access 2013. From a page on MS web site, I found the answer which solved my problem. I am sharing it here.
I copied the code safely somewhere else outside Access, in the Notepad++.
Then I deleted entire vent Procedure, with its code, which was not firing.
Created fresh Event procedure, and restored the code from Notepad++ to the newly created Event Procedure.
The event earlier not firing started without any glitch. The issue got solved.
I don't know why the problem appears. This problem has come up many times and every time it is resolved with the same solution.
Try it.
Try to decompile and recompile the database.
If that does not work, I usually create a new database and import everything from this one to the new one. If something is corrupted, I will encounter issues at that time and be able to fix it.
Can you see the code in your code modules? If so, cut and paste it somewhere safe. Then flip the HasModule setting for each form to false, repair the database, and restore the code to newly created code modules.
You decompile the database by adding the flag /decompile to the start-up options i.e.
msaccess.exe “C:\my_folder\mydb.mdb” /decompile
I find that solves most of my problems. If not then another one is to re-secure the database by running the security wizard. This basically makes a new db and imports all the objects for you
I had a similar problem. When it started I created a new version of the code by copying the database. This did not help. However, deleting the form from the new database and importing it from the original solved the issue. I did not receive any warnings of corrupted code or other. It simply just worked without any changes to the VBA etc. Bit weird all in all
I compacted the database (Access 2010) into a new one. No joy. Deleted the form that was not working and imported it from the old database. No joy. Recompiled. JOY! Not sure why it quit and why it now works. I suspect a problem with a large amount of text in a linked text box on the form.
Unfortunately, the problem is not more specific than that. I've found a few examples of people reporting similar problems by doing a Google search, but I can't find the part of the restore that is actually causing the problem, which might help me track it down on my own.
Suggestions for either resolving this problem or being able to track down the root cause would be appreciated.
There's one bug logged at bugs.mysql.com that references the error you describe:
"Bug #37253 Unable to restore backup file containing BLOBs"
The solution described in that bug is to increase the max_allowed_packet in the MySQL server configuration. The user confirmed that raising the value to 100M allowed him to restore his database.
ANOTHER FIX
I also had this problem! The answers online didn't seem to help (max_allowed_packet and others)
Here's what fixed mine:
Instead of running the Restore function, I imported through MySQL Migration Toolkit (installed with GUI Tools on Windows).
The Migration Toolkit also failed, but had descriptive errors in the Log on the final page. In my case, it was a few incorrect Date fields in my data (usually "0000-00-00") that wouldn't migrate correctly.
Fixing these dates in my tables solved the Restore problem.
Hope this helps somebody else out there.
I have had something similar in the past- it has something to do with how it was backed up. I think some applications put invalid comments in the backup files which cause errors.
My suggestion- if you are stuck trying to restore those files- is to incrementally start backing up from sections of the backup file and find what is causing the problems- which from what I recall the case for me was that they were some text in the file that was inconsequential to remove.