[shawn_h]

LeHHeL wrote on Feb 25 2007, 12:28 PM:

This is only what we want, to be more direct the “insert this-and-that in the mysql configuration file [mysqld] section”, then I can copy to clipboard and with a SSH what I have open, I can paste into my server. So I want this manually do, not with

BTW, to enable myisam recover options you do this:

[mysqld]

myisam_recover=FORCE,BACKUP,QUICK

that's all.

[shawn_h]

No, you don't have to hide away! 😀

here's what my situation was (as I believe it's now in good order). I had started with version 4.x and then installed 5.x separately to another folder. not only that, but i had a couple of other versions installed all on separate folders. only in two of these install, i had jobs running nightly. one of them was a version 4.x install (my original installation) where i had a bunch of .bat files running jobs one after the other in a specific order. the other installation was a version 5.x where i had another bunch of files but not in .bat files but just regularly scheduled jobs. these later jobs, showed up immediately when i installed the new version (beta) over my old version 5.x folder (as you've noted and i'd mentioned earlier); however, when i copied over the version 4.x jobs (the ones that are called by windows .bat files), they didn't show up in the job manager, neither the .bat files nor the actual xml jobs files showed up.

so i decided to leave it alone for now and just change the paths of my individual jobs within the .bat files. so for example, i had something like this:

“D:Program FilesSQLyog Enterprise 5.01sja.exe” “D:Program FilesSQLyog Enterprise 5.01Job Filesmy_job.xml”

changed to a more generic format/path:

“D:Program FilesSQLyog Enterprisesja.exe” “D:Program FilesSQLyog EnterpriseJob Filesmy_job.xml”

the windows scheduler, calls the .bat files (as you'd thought me to do several months ago) and the .bat files have reference to the (now newly installed and beta) sja executable.

hope this clarifies my incomplete explanations from before.

[shawn_h]

that's correct. I installed the new version over my 4.x version where I had so many jobs scheduled within bat files.

i didn't manually copy the ini file. i assume that it used the one from 4.x install. but i could be wrong. ritesh, feel free to jump in any time.

[shawn_h]

question: i had a bunch of bat files that run several jobs each. i copied these bat files together with their respective jobs files (xml files) to the new jobs folder (under the new beta version i'd just installed) but none of these are showing up in my job manager!!!!

is that by design or should any job that is in that folder (jobs folder) show up automatically???

thanks.

[shawn_h]

Great! So then, I'll just use beta 4 instead!

[shawn_h]

Interesting! Thanks for the tip on the beta version; I'll try this link http://www.webyog.com/betas/SQLyog512Ent.exe to download it. Is this beta 3 though?

[shawn_h]

Thanks Ritesh. It was great to talk to you guys as well for me. Too bad Peter couldn't make it. He's helped me along the way.

I haven't installed the new version just yet; however, if as you guys are saying, I install to the same folder, the new version will take over all the jobs and schedules from the old version. Am I correct in assuming this?

Thanks,

Shawn H.

[shawn_h]

R,

I just emailed a couple of files to you: 1- xml job file; 2- sqlyog generated log file.

Hope these help!

Also, I only have access to the source data through my windows driver. As I'd said before, the source data is and ISAM file structure on an hp alpha machine. The driver is the only way for me to communicate with the server that hosts the database. 😉

[shawn_h]

Ritesh wrote on Oct 6 2005, 10:15 AM:

Which database you are trying to import data from?

Can you send us sample data and the corresponding XML file? I dont want to guesstimate on the problem.

The problem seems to be with DEFAULT value assigned to columns.

[post=”7466″]<{POST_SNAPBACK}>[/post]

I'll send you the files here soon but not today.

[shawn_h]

I just downloaded and installed Beta5. No joy!

Here's what I get during the import in the last window titled “Completing the database Import Wizard”:

SQLyog Job Agent Version 4.2

Copyright © Webyog Softworks Pvt. Ltd.. All Rights Reserved.

Job started at Thu Oct 06 09:22:50 2005

DBMS Information: SOME_CONNECTION

Importing table schema: ABSE…

ERROR: 1067, Invalid default value for 'ID'

Check d:Program FilesSQLyog Enterprise Beta5sja.log for complete error details.

Total time taken – 10 sec(s)

And here's what is in the log:

Job started at Thu Oct 06 09:22:50 2005

ERROR: 1067, Invalid default value for 'ID'

Basically the same thing. Shouldn't the log be a little more descriptive of the error/issue/problem??? 😕 After all, it does say check the log for more details!!! 😉

[shawn_h]

peterlaursen wrote on Oct 6 2005, 04:20 AM:

@Shawn

Can you confirm that beta5 works with you?

[post=”7447″]<{POST_SNAPBACK}>[/post]

I haven't tested beta5! Where can I find the code? Is it under the downloads section? 😕

I'll look!

[shawn_h]

Ritesh wrote on Oct 5 2005, 04:13 AM:

Thanks. I will work upon it in some time 🙂

Still feeling lethargic from yesterday's fever  :huh:

[post=”7434″]<{POST_SNAPBACK}>[/post]

My recommendation is that the default statements not be generated at all even if the source table contains them. It should be left to the dba to decide if a column should need a default value in the new table that is going to be created by the current job. And that does include the generation of NULL statements. If there is no need for it, let's not put it in there. Or maybe make it optional per table and/or jobfile by havig a form control with the capability to verride it per column, ey?

Pretty simple, ey? 😉

[shawn_h]

peterlaursen wrote on Oct 3 2005, 03:34 PM:

There are a lot of early database systems that came to existence before and the early years of the ODBC-standard (we are talking about the beginning of the 90'ties) that were later made “ODBC-compatible”.  Most of them have non-standard-issues.  I guess that is the problem here.  But SQLyog has implemented workarounds for similar issues (and regular bugs) with other databases.  I shal not exclude that there is one more of the kind possible.

[post=”7416″]<{POST_SNAPBACK}>[/post]

I agree with you on the ODBC compliancy issues specially in the earlier stages; however, the fact remains that when a dba chooses to have default statements for columns generated by SQLYog, then those statements should be there, but if the dba doesn't choose to have any and/or no default statements, then there shouldn't be any included. The choice should be the dba's, don't you agree? I mean I don't have to go through each xml job file and edit those statements out every time I want to generate a new job file! It doesn't make sense to have to do that.

[shawn_h]

peterlaursen wrote on Oct 3 2005, 01:01 PM:

Or maybe rather a problem with the source database.

is it not possible to remove the DEFAULTS from the table-definitions on the source database (if they are there)?  If the database implementation is so that DEFAULT = NULL is the only way to specify 'No default' then there is a problem!  You never know what kind of “workarounds” have been made in the early ages of ODBC-implementation!

[post=”7413″]<{POST_SNAPBACK}>[/post]

You're missing the boat. The problem is not in ODBC at all. The problem is with table creation and DDL that SQLYog generates to create the objects. This statement “NULL” should not be included in the DDL automatically!!!

There shouldn't be any “” statements at all in the DDL unless the dba chooses so either for a specific column and/or for a specifc table (would be nice to have this so that the dba can turn it on or off at will for the whole table). That's all!

Maybe earlier version of MySQL let that go without spitting it back up; however, the new version apparently doesn't allow it.

I am sorry but I hope I am making myself clear on this! 😛

[shawn_h]

peterlaursen wrote on Oct 3 2005, 12:29 PM:

shawn!!!

Send that file to [email protected] and delete the attachement here.

Never expose your user credentials like this!

[post=”7410″]<{POST_SNAPBACK}>[/post]

Don't worry, All the credentials are fake! However, I'll go ahead and delete the file regardless. Thansk 😉

[Author]

Posts