*.sql is ASCII, not binary. How do I fix this so I can see differences?

Asked by rod boggess on 2011-07-01

I have a CreateDB.sql file that SQL Server can open and execute the create an entire database with users, user access, etc. It's a text file that can (and is) edited in Notepad++. Whenever there's a change to the database, this file is updated and needs to be maintained by Bazaar. But when I run a differences, it categorizes it as a binary file and won't show differences. I don't know if this is a Bazaar issue or a TortoiseBzr issue, but I'm hoping someone on here can help me figure out how change the way it's recognized so I can see differences.

Question information

English Edit question
QBzr Edit question
No assignee Edit question
Solved by:
Martin Pool
Last query:
Last reply:
Best Martin Pool (mbp) said : #1

I'd guess you might be saving it in UCS-2, and you should choose UTF-8
in the file/save as dialog, or perhaps there actually is binary data
in it?

rod boggess (rboggess) said : #2

Well, I don't know how smart Notepad++ is, so I opened the *.sql file in Notepad. No squares or other indications of wide characters or binary data, so I'd say no. Any better way to verify? I don't have a save-as option that offers UTF-8 or UCS-2. But aren't both of these text, rather than binary anyway? Why would this prevent bzr from doing a differences?

rod boggess (rboggess) said : #3

Thanks Martin Pool, that solved my question.

rod boggess (rboggess) said : #4

Correction. I found in Notepad++ (this program rocks) where the encoding is saved. I still don't understand why this matters, since they are both text, but indeed it does and that fixes my problem. Thank you ever so much!

Alexander Belchenko (bialix) said : #5

qdiff from QBzr looking for null characters in your file, and if there is at least one, it marks the file as binary.

rod boggess (rboggess) said : #6

Well, that explains it. I still don't understand, but at least my lack of understanding is better informed. :)

I have to wonder if there isn't a better way to determine binary/non-binary than a null character, especially with so many encoding types using nulls for wide characters. Worse that they didn't have the foresight to allow end-users to override this default choice.

Martin Pool (mbp) said : #7

The problem is probably <https://bugs.launchpad.net/bzr/+bug/267296>;
this will be fixed but it's not fixed yet.

rod boggess (rboggess) said : #8

That looks like it exactly. Thanks. I hope the fix doesn't get dropped off as it appears to be now.