Though little late in reply, but no change needed, if you are dealing with debug build (most of developers deals with debug version). Digital signature checking is guarded now.

HMODULE loadSciLexerDll() { generic_string sciLexerPath = getSciLexerFullPathName(moduleFileName, 1024); // Do not check dll signature if npp is running in debug mode // This is helpful for developers to skip signature checking // while analyzing issue or modifying the lexer dll #ifndef _DEBUG bool isOK = VerifySignedLibrary(sciLexerPath, SCINTILLA_SIGNER_KEY_ID, SCINTILLA_SIGNER_SUBJECT, SCINTILLA_SIGNER_DISPLAY_NAME, false, false); if (!isOK) { ::MessageBox(NULL, TEXT("Authenticode check failed: signature or signing certificate are not recognized"), TEXT("Library verification failed"), MB_OK | MB_ICONERROR); return nullptr; } #endif // !_DEBUG return ::LoadLibrary(sciLexerPath.c_str()); }

Yeah, the header detection needs improvement.
The goal with CsvQuery has always been to detect everything automatically, usually (e.g. Excel and SQL Server) when reading CSV you always have to enter separator char, “has header row” etc.

But this detection can be tricky.
It works by reading 20 lines or so, and try to guess the type of each column.
If the first row had only strings, but all other rows had at least one (common) number column, it assumes the file has a header row. Yeah, not exactly foolproof. There is a reason the only issues in github right now is Better detect header row and Add “has header row” to Manual Parse Settings (so you can force it when it guess wrong) :P

And yes, the MSSQL code use a different header detector right now, since I’m writing a generic one both can use, but the SQLite code still use the old detection.

Regarding the “already an object named ‘this’” error - yeah, bug. SQLite is much more forgiving than MSSQL :)

I’m curious if you determine data types in the plugin, or does sqlite make it’s own guess? How does it know what type to make a column when it imports the csv into SQL Server?

In MSSQL there is currently no (working) type detection. SQLite doesn’t have column types, everything is strings. So “Sum()” etc is done by type converting on the fly. Apparently SQLite can handle euro :)

Many many thanks, i looking for something like it for long time…
Best wishes for you

Add your issue at https://github.com/jeanpaulrichter/nppcrypt/issues to get the necessary attention.

@pnedev
Thanks for the tips. Now it works.
I think I was confused with the two parameters “generic database config” and “current database config”

I’ll use it for several days and i’ll get back to you for some suggestions.

Thanks for the updates (>here<, with the clarification, and >there< with the new version 1.3.2). I updated to 1.3.2 as normal.

Also, thanks for making the useful plugin in the first place.

Interesting point about 32- vs. 64-bit plugins. I have been using 32-bit Notepad++ on my 64-bit system, a conservative approach, because I assume the availability and stability of 32-bit plugins is better than of 64-bit plugins.

I think that’s exactly the information I to get started. I figured Claudia-Frank would have already posted something along those lines before. Thank you for finding those Scott!

@Alessandro Thanks, in fact compiling in VS 2015 solved the issue.

@jkriege2

see https://sourceforge.net/p/analyseplugin/code/HEAD/tree/trunk/.

Cheers
Claudia

@Meta-Chuh

Compare does diffs at a word level and lines up matching lines even if all words do not match. Not WinMerge, UltraCompare, or ExamDiff Pro, at least not that I have found. Compare’s 32/64 bits only issue I have is it will not compare large files with lot’s of diffs. I’m comparing a 6.5mb file to a 11.5mb file. If copy each file and make a change to the copy, then compare to the original, no problem.