Forum Replies Created
-
AuthorPosts
-
mattRobertsonMemberManoj wrote on Oct 17 2006, 08:50 PM:From SQLyog 5.1 MySQL KEYWORDs are given a special treatment by the GUI!
Has this bug been fixed? I brought it up around v5.14 and was told that the keywords feature would become user-configurable so the GUI's ability to silently destroy data would be mitigated. (if SQLYog encounters an existing 'default' string it will destroy it in the existing record). I see the user configurability has been added but the docs are silent with respect to any new ability to keep SQLYog from performing this behavior, which is catastrophic for users of my CMS.
mattRobertsonMemberpeterlaursen wrote on Jul 31 2006, 04:25 PM:What are the MySQL versions and what TYPE is column 'ID' ?FULL definition for 'ID' please (NULL/NOT NULL … DEFAULT .. everything!! )
here's the table spec:
cm_approvers CREATE TABLE `cm_approvers` (
`ID` int(10) NOT NULL auto_increment,
`ParentID` int(10) default NULL,
`ApproverID` int(10) default NULL,
`ApproverType` char(1) default NULL,
`Reviewed` char(1) default NULL,
`ApproverEmail` varchar(255) default NULL,
`Comments` text,
`LastReview` varchar(50) default NULL,
PRIMARY KEY (`ID`),
KEY `ParentID` (`ParentID`),
KEY `ApproverID` (`ApproverID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Both servers are 5.0.22-community-nt
mattRobertsonMemberSorry I have been away for a bit. I have already created the dummy user and the job via the wizard. I did not run it immediately. I did however decide to run it as-is… as the wizard created it by default.
The execution string in the Scheduler is
“C:Program FilesSQLyog Enterprise Trialsja.exe” “sqlYogTest” -l”C:Program FilesSQLyog Enterprise Trialsja.log” -s”C:Program FilesSQLyog Enterprise Trialsjasession.xml”
The task executes and returns a 0x0 code which means Success as far as Windows is concerned.
The contents of sjasession.xml read as follows (sjalog.txt is unaltered)
Definition mismatch for 'ID' column in '`cm_approvers`' table This error is bogus as this is a first-time, one-way replication to an *empty* target database. So a mismatch is impossible. No tables or data of any kind are copied.
Ignore the folder name. This is a registered version of Enterprise.
I'll try and run per your previous post as soon as time permits.
mattRobertsonMemberpeterlaursen wrote on Jul 22 2006, 01:21 PM:Once the job is saved with the Scheduler the 'complete list of clicks and keypresses' are forgotten.Yes of course. But that presupposes the program that accepts the inputs properly does its job based on same. I do not think so myself. If you have a passing understanding of Windows permissions then if the job runs at all then it is permissioned properly and responsibility for job execution then belongs to the called application. SQLYog plants the scheduled task, and it runs that task. That task runs… which is alll that Windows can be tasked with … but fails to achieve desired results (at least so far as on win2k3 is concerned). So what is wrong? If Windows is running the thing its not a windows issue. Its an application issue.
As I said before I found my own workaround. But 'workaround' means something isnn't working right in the first place. If your implication is you have studied my inputs in detail and come to the conclusion that nothing is wrong with them, then something in the o/s — a bare win2k3 o/s — dsagrees with your program.
mattRobertsonMemberpeterlaursen wrote on Jul 22 2006, 08:33 AM:However I still thnik is a issue with the scheduler.I think I know what you mean by scheduler issues. The Win Scheduler is famous for not running when you don't run it under the proper permissions. However, consider this:
1. When I create the job via the wizard the Scheduled Task runs, right down to leaving SQLYog log entries. The log entries just show the process read the source and read the target and did nothing.
2. When I create the job manually and schedule it as an “sjajob” file type it runs perfectly
3. I am using my logged-in username and password (and watched it run while I was logged in too) so Windows permissions are completely out of the picture.
Somewhere in that complete list of clicks and keypresses I gave you is a flaw. Either bad user behavior that should be FAQ'd as a warning to others or its the program. If you want screen shots of every step I can provide them. They would include the real db locations and such so its not something I would post on an open forum, so if you want to pursue this shoot me an email.
Lastly, I did indeed register the file types prior to scheduling so they are also clickable straight from the explorer. I didn't try the “exe + parameter” method.
mattRobertsonMemberUnfortunately its not as simple as Windows permissions. If you note in my first post, the scheduled task is running. Its just not doing anything. In the example I gave, I have a live database filled with tables and data. I also have a backup database on a second server. SQLYog is running on this second server. If I do a 'run immediately' it runs as expected and copies what it should. If I let it run via the scheduler it runs… but as the log shows that I posted, it doesn't do anything.
Its also not mySQL permissions. The db only has one user: “root”, and as you can imagine it has full rights. And again, if I 'run immediately' it works great. If it were mySQL permissions then it wouldn't run on 'run immediately', or provide undesirable results.
As for the second link you provided, I used the second option and it seems to work fine. (naming job files with a .sjajob extension and scheduling them directly). Works perfectly.
FYI the o/s is win2k3 Standard.
No idea why the wizard doesn't work but doing it manually does. Don't much care as I'd rather write a quickee xml file than run a wizard anyway.
🙂
Getting the synch tool was the last obstacle to buying another copy of Enterprise. I've just ordered a copy so I don't create 40 scheduled items whose paths I have to change later on.
mattRobertsonMemberpeterlaursen wrote on Jul 20 2006, 05:52 PM:Suggestions are welcome .. but I am not sure I understand this one!You aren't alone. I thought I had figured out what I was doing wrong, but I haven't.
I'll go thru the steps I am taking, step by step. Tell me where the error is if you can please.
- click the synch icon, choose 'start a new session' and click 'Next'
- Pick a source host and db, then do the same for the target. Click 'Next'
- Choose advanced options and click 'Next' (in my case I am doing simple 1-way synch)
- Check 'ALL' and click 'Next'
- Check “Save & Schedule” and choose to schedule via Windows Scheduler. I am not telling it to run immediately (if I do it runs fine, and this is the only time I can get it to run). Set the session XML file to the name of the database for clarity, so if the db is 'abc' then the window reads “C:Program FilesSQLyog Enterprise Trialabc.xml”. Click 'Next'.
- Specify the job file AND the schedule name as 'abc'. Click 'Next'
- Now the scheduler window pops up. Program to run is “C:Program FilesSQLyog Enterprise Trialsja.exe” “abc” -l”C:Program FilesSQLyog Enterprise Trialsja.log” -s”C:Program FilesSQLyog Enterprise Trialabc.xml”
- I schedule it for a given time and permission it.
- When it runs, its just a dos-window blip onscreen. on and off in an instant. If I check the target db its still empty when it should have 50 tables and a few thousand records in it.
- If I examine the folder where the SQLYog files are located, the only file that has been created is called 'abc' (no extension) and it contains what you see below (sanitized of locations and passwords course).
What am I doing wrong?
moe.source.net ********** ********** 3306 [default] abc localhost ********** ********** 3306 [default] abc mattRobertsonMemberNever mind. I figured it out. If I might make a suggestion:
Have the user pick the 'name' at the beginning of the process. Then carry that name through and pre-populate the fields for session file, job file and schedule file with that name. What happened was all of my session files were named sjasession.xml within the wizard and I didn't realize that what looked like just a folder pane (the name scrolls off the screen) is really a file/folder name that must be renamed from the default manually.
mattRobertsonMemberpeterlaursen wrote on Jul 19 2006, 04:10 PM:We will discuss that.BTW: Please observe too that also functions are evalutated.
Hopefully nobody has something like that in a data field. It is unlikely but nothing is impossible.
I would suggest the default behavior is to shut this feature off, since it can — and in my case did — result in data alterations without any direct action on the part of the developer. If I hadn't had a freebie 5.02 sitting on another machine I (or more accurately my client) would have been out of business until I wrote and ran manual SQL queries to replace the destroyed data. It doesnt' take long to write a query but it took a couple of hours to figure out which of the dozens of tables was throwing an error and why.
mattRobertsonMemberpeterlaursen wrote on Jul 19 2006, 05:34 AM:it is all explained here:http://www.webyog.com/faq/8_99_en.html
I think your column is defined as DEFAULT NULL ?
For those few words that are KEYWORDS, you must enclose the string in backquotes like `default` .
Yes that fixed it. Thank you!
So if you ever edit a record with one of these values in it, SQLYog will assume you want its SQLYog-specific behavior and — if that assumption is incorrect — corrupt it. And this is by design? I have a GUI so I can edit the data myself, not so something can decide to edit it for me. If there is no way to turn off this behavior I could wind up corrupting any database record I touch. I go into client systems every day and many times I haven't got a clue whats inside until I look. I can't just go in and change a field that needs it anymore as SQLYog could break the record? Thats not something I should ever have to worry about from a DB GUI.
In the case of the cms I am editing, thankfully I don't use this so much that I can't provide some instruction to work around it. But this is a built-in way for your product to crash the client's entire application if they forget that instruction.
I can see where the words other than “default” are highly unlikely to see themselves placed as standalone values, but “default” itself seems mighty common, and its of course not a reserved word in mySQL itself.
How can this be disabled? Honestly I have never heard of a db fornt end that will decide for itself what it will do with existing data that it wasn't expressly asked to alter by the user, and am a little dumbfounded to find out the behavior was deliberate.
At least put in a switch somewhere in preferences!
mattRobertsonMemberNothing further? I need to do a fully clean uninstall to be able to install Pro. See previous post.
mattRobertsonMemberSorry for the delay in getting back to this. I found at least the cause of the problem, although I'm still stuck in some respects (I can install to a fresh machine and it works, but its the wrong machine):
I installed Pro over top of Free (i.e. into the same directory on my workstation). This had the effect of not affecting Lite at all (a surprise) and rendering Pro inoperable only in the sense that it runs but cannot connect to anything.
So I uninstalled both, and then reinstalled Pro. Same problem with Pro: Works but cannot connect, even to localhost.
So how do I solve this? i.e. how do I render my workstation capable of running SQLYog again? I noticed on the reinstall that I did not have to register again, so the uninstall is not completely 'clean' in this circumstance. I first uninstalled Free, then Pro. Then figuring maybe something was left behind thanks to the above I installed Pro, then uninstalled, then reinstalled. Still no registration prompt, so the uninstall is not apparently a clean one.
I suggest accounting for this possibility in your installer. Its not uncommon behavior for a system to detect existing installs of itself and to deal with same accordingly.
Also your installer shows errors but doesn't give any sort of way to display them so they can be read. They just zip by onscreen and then the window closes. All I know is there were errors on the install as I saw that word fly past but I couldn't read details. There's no install.log that I can see.
mattRobertsonMemberRitesh wrote on Apr 3 2006, 06:53 PM:Indeed you can have both the versions installed on the same system at the same time.Are you sure you are providing the correct and same connection info for both the versions? The error seems to be that you are not providing the correct host/domain name.
Can you disable your firewall and try once again?
I'm sorry I failed to say earlier that the first thing I did was disable the firewall. And then I checked the Windows Process list to make absolutely sure it was gone.
And yes I'm afraid I am absolutely sure that I am proviiding the same connection info. I have made repeated attmepts and used cut/paste between both versions to ensure no possibility of typographic errors. I have three servers available, and it cannot even connect to
server: localhost
username: root
password: [blank]
However the free version of sqlYog has no problems with the above connection as well as the other two. Further, the 'localhost' connection has no network or firewall issues… its all the same system.
Intranet Server is Win2k3 Standard Server. Desktop is win2k Pro and web server is win2k Server
-
AuthorPosts