I need to import an excel 2007-2013 file into MSSQL but the characters are being truncated within a column. The quick fix is to sort the rows from largest to smallest interns of character sting length.
I require a permanent solution and the following answer (see below) worked for .exe files however what will be the corresponding solution for .xlsx files.
Thanks
Chantelle
To change the value of TypeGuessRows, use these steps: 1.On the Start
menu, click Run. In the Run dialog box, type Regedt32, and then click
OK. 2.Open the following key in the Registry editor:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel
Note For 64-bit systems, the corresponding key is as follows:
HKLM\SOFTWARE\wow6432node\microsoft\jet\4.0\engines\excel
3.Double-click TypeGuessRows. 4.In the DWORD editor dialog box, click Decimal under Base. Type a value between 0 and 16, inclusive, for
Value data. 5.Click OK, and then exit the Registry Editor.
A second way to work around this problem (without modifying the
registry) is to make sure that rows with fields, which have data 255
characters or greater, are present in the first 8 rows of the source
data file. shareedit
answered Jan 20 '14 at 11:21
Suji 112
Related
Evening,
I'm bashing my head against a wall with the following problem:
I'm loading numbers from cells from a Number column with size=16
and decimal places = 2 inside adBase III .dbf file.
These numbers, when viewed with a DbfViewer appear as: 12345.12, where there is no thousands separator and the decimal
separator is ..
I parse the number from the cell in the database using decimal.parse(val).
I do stuff with that number.
I am using the ClosedXML library to paste the number into an .xlsx Excel file cell with the following formula: "=R[-1]C * 100/" & val where val is the value I obtained from the dBaseIII database file. This is done with the following statements:
Dim formula as String = "=R[-1]C * 100/" & project.TotalIncome(i)
cell.FormulaR1C1 = formula.
I am using two programming environments:
A Windows 8.1 machine with Visual Studio 2013 Community and Office 2010.
A Windows 8.1 machine with Visual Studio 2013 Ultimate and Office 2013.
I have made sure that both environments have the same Language, Date, Time and Number format, both for Windows and Office.
When I build and execute the program from the Option 1 Environment, everything pastes fine inside the Excel file. I navigate to the cell containing the formula, and whether or not the value obtained had decimal places, the formula is there.
However, If I build and execute the program from the Option 2 Environment, I get a:
Removed Records: Formula from /xl/worksheets/sheet.xml part
Removed Records: Formula from /xl/calcChain.xml part (calculation properties)
I tried adding a breakpoint in Environment 2, opening the Locals window and editing those values which had decimal places and everything worked as intended, whereas when I use Environment 1 I have no trouble whatsoever when the value has decimal places.
I have tried the following (in Environment 2):
Dim nfi As NumberFormatInfo = New CultureInfo("es-ES", False).NumberFormat
nfi.NumberDecimalSeparator = ","
value = Decimal.Parse(row("VALUECOL"), nfi)
also:
value = Decimal.Parse(row("VALUECOL"), New CultureInfo("es-ES"))
To no avail.
I have opened the XML file containing the Excel Sheet info in Environment 2 and found this:
<x:c r="L101" s="41">
<x:f>L100 * 100/57125,71</x:f>
</x:c>
Whereas the definitions for the same XML file created by the Environment 1 has the following cell value:
<x:c r="L101" s="41">
<x:f>L100 * 100/57125.71</x:f>
</x:c>
So, is it a Visual Studio Locale thing (which both have the same, as far as I can see), or am I missing something else?
EDIT: Printing out the current Locale with:
Console.WriteLine(CultureInfo.CurrentCulture.Name)
yields the same es-ES on both Environment 1 and Environment 2.
EDIT 2:
Taken from: Microsoft Office XML formats. Defective by design.
To save them time, Microsoft chose to store XML using the US English
locale regardless of all settings above. [...]
Also, for Excel formulas, it means the formula names are US English
formula names, [...] it implies you are willing to work with US English
function names (plus US English separators, ...).
So basically it all boils down (I believe) to a pre localisation of the decimal value into the Excel XML taking into account something, somewhere.
In Environment 2, any other (non-formula) value I write to the Excel file appears in the XML as an en-US localised value (i.e. 12345.12). Most of them brought in by a dataTable import. However, since writing a formula requires the input of a string, and Visual Studio applies locale settings to said string, it ends up as 12345,12 in the Excel XML, which results in the previously mentioned errors.
So, what on earth is Visual Studio taking from Environment 1 that is different from Environment 2? All possible UI localisation options are exactly the same in both machines...
I had a similar issue before, and found that there was a different dll file in my project references. The dll's were named the same, I only noticed because of a file size difference. Once I manually linked to the same one on both Dev machines, I got the expected results.
Like I said, my issue was different... But it did also involve excel files, and I did have Excel 2010 on one Dev machine and 2013 on the other.
I don't even know if this qualifies as an answer since I still have no clue about where's the localisation variable that Environment 1 has different from Environment 2.
However, It seems Visual Studio -when using different localisations- deals internally with de-localised decimal variables, but with localised string variables. Even when checking the locals panel during debugging, the value of a decimal number stored in a dictionary entry will appear as its localised version on the keyValuePair entry, and as a de-localised en-US value when expanded:
Hence, when outputting a dataTable as a whole to the Excel file, it's written onto the XML as en-US values. On the other hand, when outputting a formula (a.k.a. a string) it pours over the localised version of the associated decimal value.
Conclusion: When dealing with Office files in localised systems, just write the data as de-localised (i.e. en-US) and let the software localise it for you.
Ended up doing the following dirty patch:
Dim formula As String = "=R[-1]C * 100/" & project.TotalIncome(i).ToString().Replace(",", ".")
I have used the "Hex Editor to modify DPB to DPx" many times in the past to bypass VBA project security on my old Excel VBA projects (.xls), so I definitely know how to do it and know that I can do it.
However I have just tried to do it yesterday and found that it no longer seems to work. I tried using both Excel 2011 (Mac) and Excel 2003 (Windows) and in both cases, I got the same behaviour;
Opening the VBA editor gave a message saying that the project is corrupted and that the project will be removed. The VBA editor then opens and, sure enough, all VBA is stripped out from modules and worksheets.
I have tried this method:
Is there a way to crack the password on an Excel VBA Project? (ie. creating a spreadsheet with a known password and then copying across the relevant fields)
But find that the length of the "GC" key created on my 'dummy' spreadsheet is shorter than the "GC" key on the spreadsheet that I am wishing to access (the "target"). I had read elsewhere that in cases where the "target" keys were longer, you could pad the "dummy" keys to the same length but there is nothing i can find to say what to do in the reverse case.
So - my questions (s);
Is anyone aware if a patch has been applied that makes the "hex editor" approach invalid?
Can anyone help with what to do when the dummy keys are longer than the target keys?
Can anyone else provide any updated onsite into this issue?
EDIT
Having now solved this (to some degree) i thought i'd add a summary here.
I HAVE NOT been able to get this to work on Mac Excel 2011. Something about changing the file from filname.xlsm to fielname.zip and back again results in a corrupted excel file which Excel 2011 refuses to recognise.
I DID manage to get this to work on an old windows machine (XP/Excel 2007) by modifying the .xlsm file name to .zip, editing the DPB= AND GC= values in the vbaproject.bin file with a hex editor then saving this in the .zip file before renaming the .zip back to xlsm. I used the "test" example given by Ricko at the bottom and it worked with ONE CAVEAT - i had to 'pad' out my GC value to make it that same length as the original one in my file.
ORIGINAL: GC="0F0DA36FAF938494849484"
NEW: (TEST) GC="BAB816BBF4BCF4BCF4" (from Ricko below)
NEW: (TEST) GC="BAB816BBF4BCF4BCF40000" (what i used and what worked)
I have your answer, as I just had the same problem today:
Someone made a working vba code that changes the vba protection password to "macro", for all excel files, including .xlsm (2007+ versions). You can see how it works by browsing his code.
This is the guy's blog: http://lbeliarl.blogspot.com/2014/03/excel-removing-password-from-vba.html
Here's the file that does the work: https://docs.google.com/file/d/0B6sFi5sSqEKbLUIwUTVhY3lWZE0/edit
Pasted from a previous post from his blog:
For Excel 2007/2010 (.xlsm) files do following steps:
Create a new .xlsm file.
In the VBA part, set a simple password (for instance 'macro').
Save the file and exit.
Change file extention to '.zip', open it by any archiver program.
Find the file: 'vbaProject.bin' (in 'xl' folder).
Extract it from archive.
Open the file you just extracted with a hex editor.
Find and copy the value from parameter DPB (value in quotation mark), example:
DPB="282A84CBA1CBA1345FCCB154E20721DE77F7D2378D0EAC90427A22021A46E9CE6F17188A". (This value generated for 'macro' password. You can use this DPB value to skip steps 1-8)
Do steps 4-7 for file with unknown password (file you want to unlock).
Change DBP value in this file on value that you have copied in step 8.
If copied value is shorter than in encrypted file you should populate missing characters with 0 (zero). If value is longer - that is not a problem (paste it as is).
Save the 'vbaProject.bin' file and exit from hex editor.
Replace existing 'vbaProject.bin' file with modified one.
Change extention from '.zip' back to '.xlsm'
Now, open the excel file you need to see the VBA code in. The password for the VBA code
will simply be macro (as in the example I'm showing here).
New version, now you also have the GC=
try to replace both DPB and GC with those
DPB="DBD9775A4B774B77B4894C77DFE8FE6D2CCEB951E8045C2AB7CA507D8F3AC7E3A7F59012A2"
GC="BAB816BBF4BCF4BCF4"
password will be "test"
Open xls file with a hex editor.
Search for DPB
Replace DPB to DPx
Save file.
Open file in Excel.
Click "Yes" if you get any message box.
Set new password from VBA Project Properties.
Close and open again file, then type your new password to unprotect.
Check http://blog.getspool.com/396/best-vba-password-recovery-cracker-tool-remove/
If you deal with .xlsm file instead of .xls you can use the old method. I was trying to modify vbaProject.bin in .xlsm several times using DBP->DBx method by it didn't work, also changing value of DBP didn't. So I was very suprised that following worked :
1. Save .xlsm as .xls.
2. Use DBP->DBx method on .xls.
3. Unfortunately some erros may occur when using modified .xls file, I had to save .xls as .xlsx and add modules, then save as .xlsm.
I have a scenario and would like to see if anyone has any suggestions on how I should tackle it. Basically I have a directory full of files, document names consist of [Code]-[number]-[text]
CODE - A generic 3 letter code.
NUMBER - a number generally 4 - 5 digits in size.
TEXT - original document name (Before it was dumped).
CODE, NUMBER and TEXT are separated by a colon (-). Number always starts at the 5 character.
I would like to somehow scan that directory and extract the number from the filename, I would then like to compare that number to a field in a database (SQL query fairly straight forward, could also extract as raw text) If the number matches the number in the database I would like to separate those files.
If I need to clarify anything please ask. I wasn't sure if this site is appropriate for my query.
Open the root folder, click in the file explorer path (in open space off to the side so the whole path gets highlighted), type cmd and hit enter to open a command prompt from that folder location.
Type: dir /b /s > filelist.txt to get a list of all file names. You can exclude /s if you don't need/want to dig down into subfolders.
I'd paste that into excel, if you have 2013 you can just start typing the part you want to extract, after you type the full first line when you start typing the next line it will recognize the pattern and you can just hit enter to fill down.
Otherwise, use Data > Text to Columns and specify - as a delimiter.
Likewise you could just import the filelist, separate them in SQL using SUBSTRING() or similar. When you have your matching filenames you can just use some concatenation to build a COPY or MOVE .bat file, pretty easy in SQL or Excel.
Does anybody else have this same problem, when you import data from Excel file to MSSQL Server 2005, if some column contains mostly numeric data, but even if you set the column type to varchar, the wizard fails to import those fields that fail to parse as numbers?
Try this (Note: These instructions are based on Excel 2007)...
The following steps should force Excel to treat the column as text:
Open your spreadsheet with Excel.
Select the whole column that contains your "mostly numeric data" by clicking on the column header.
Click on the Data tab on the ribbon menu.
Select Text to Columns. This will bring up the Convert Text to Columns Wizard.
-On Step 1: Click Next
-On Step 2: Click Next
-On Step 3: Select Text and click Finish
Save your Excel sheet.
Retry the import using the SQL Server 2005 Import Data Wizard.
You need to edit the connection string that SSIS uses. Add this to the end of the string "IMEX=1;" (No quotes) That tells SSIS/jet to not try and figure out what the data types are. Just import them.
You might try tweaking Jet settings for importing Excel data. You can force the Jet engine to sample the entire sheet when trying to determine the column type during a given import. Change the following registry key (after making a backup first) and see if that doesn't do it:
HKLM\Software\Microsoft\Jet\4.0\Engines\Excel
Or on x64
HKLM\Software\Wow6432Node\Microsoft\Jet\4.0\Engines\Excel
Set the value TypeGuessRows equal to zero. This will force Jet to sample all rows to determine the column type.
Create a new column that is an apostophe + the contents of the column you want to import. This will force it to be a string
="'"&E2
Adding IMEX=1 BEFORE the HDR setting worked for me.
This is the best solution:
Click File on the ribbon menu, and then click on Options.
Click Advanced, and then under When calculating this workbook, select the Set precision as displayed check box, and then click OK.
Click OK.
In the worksheet, select the cells that you want to format.
On the Home tab, click the Dialog Box Launcher Button image next to
Number.
In the Category box, click Number.
In the Decimal places box, enter the number of decimal places that
you want to display.
I know that often using a for loop to generate repetitive content is the better way than pasting something 20 times and changing each paste to the correct number by hand. But let's say for cases where content is hard-coded and I just want a list from 1-20.
I would like a text editor with a "smart" paste command that takes any number imbedded in a string on the clipboard and increments it each time I paste. If it doesn't exist, I will make a plugin.
I'm trying to think of a good 2-stroke keyboard shortcut to do it, close to the ctrl-V. Maybe ctrl-g or numpad_+ (in an app with no zooming).
Does it exist?
In Zeus this can be easily done as follows:
Column mark the area to be converted to a numbers
Use the Macros, Execute Script menu
Type in numbers to run the numbers Lua macro
Type in the first number of the sequence
The marked area will be replaced by an incrementing sequence of number starting at the first number provided in step 4.
I'm trying to think of a good 2-stroke
keyboard shortcut to do it,
Making this into a key stoke action is as simple as binding the numbers Lua macro to the keyboard.
Here is an example of how it works. If 1 values in the text below are column marked and the macro executed with a starting number of 1000:
Field_1
Field_1
Field_1
Field_1
the following text changes will be made:
Field_1000
Field_1001
Field_1002
Field_1003
Armed bear J has a renumber region command, as well as a case-preserving replace-in-files, which means I often keep it around for those features.
TextPad is another text editor with a Fill Region function, for filling with a character, a string, or incrementing numbers (starting from X, with left- or right-alignment, and space- or zero-filled.)
I used Notepad++ now, but I have to keep TextPad around just for that number-filling function.