i have module with text objects and ole objects inserted as icon.
I need to parse the object and if an ole object is present in that attribute, retrieve the name of the ole object.
Unfortunately, I have no idea on how to get this information.
Is there a simple way to get the OLE file name?
I don't think that there is a simple way.
I just tried the following code
Object o = current
string s = richTextWithOle(o."Object Text")
print s
and looked for the filename.
The result was something like
{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1031{\fonttbl{\f0\fnil\fcharset0 Tahoma;}}
{\*\generator Riched20 10.0.18362}\viewkind4\uc1
\pard\sa8\f0\fs20{\object\objemb{\*\objclass Word.Document.12}\objw1440\objh1215{\*\objdata
01050000
01000000
11000000
576f72642e446f63756d656e742e313200
33000000
443a5c4d53435c446f63756d656e74735c414d495220766f6d2057617274656e20617566204672
6569686569742e646f637800
00000000
Part of the file name was "AMIR". Which in ASCII is 41 4D 49 52. Which is part of the 6th line of the objdata.
Perhaps it is possible to create a general rule and some code from this observation.
Good luck!
So... there is not a simple way, unfortunately.
Take a look here: https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014438813
The solution ends up being activating the ole in whatever program it relies on, then grabbing the name using oleGet commands. Ugh.
Related
I will provide some context before I ask my question.
I am attempting to query an SQL Server and create a table within Excel from the data. Because I am not familiar with how to accomplish this in VBA I recorded by using Data -> Get External Data -> From Other Sources -> Microsoft Query. In the dialog box that appears, I chose a .DSN file provided to me by someone else. I then used the Microsoft Query interface to structure the query and import the data onto a worksheet.
The code in the recorded macro looked something like this. I will use generic terms instead of the actual code.
With Sheet2.ListObjects.Add(SourceType:= 0, Source:=Array _
(Array("ODBC;DRIVER=SQL Server;SERVER=ServerName;UID=userid;Trusted_Connection=Yes;APP=Microsoft Windows Operating System;WSID=SomeString"), _
Array("A;DATABASE=DatabaseName")), Destination:=Range ("Sheet2!$A$1")).QueryTable
I know this is not formatted ideally, which is part of my question below.
https://msdn.microsoft.com/en-us/library/bb211863(v=office.12).aspx
From the above article, I know that SourceType:= 0 is an xlSrcExternal, or an external data source. This makes sense to me.
My confusion begins to arise when I get to the Source component of the Add method. From the provided article, "When SourceType = xlSrcExternal, an array of String values specifying a connection to the source, containing the following elements:
•0 - URL to SharePoint site
•1 - ListName
•2 - ViewGUID
So to begin with, what exactly is meant by "an array of String values", as the code from the recorded macro does not appear to correspond to what I thought was an array. I know that normally an array is declared something like this Array("string1", "string2", etc.). Or is the array recorded simply an array of one value? In other words Array("string1"). Does anyone know the purpose of passing an "array of string values" as opposed to just passing a string?
Also does anyone know the nuances of why the recorded macro has this particular formatting/syntax? In other words, why does it appear to have this syntax Array(Array("string1"),_ (new line) Array("string2"))? Why not just Array ("string1")? Does it have something to do with the second line being too long?
I have several more questions related to this topic, but this seemed like a good place to start..
Thank you all for any help given.
Trying to use this:
substring(#[User::v_Filename],37,3)
However, it seems substring can only handle 20 characaters ?
The file name looks like this:
D:\Projects\OTS\MYSSA Dashboard\Data\ATL_20150725Text.csv
All I want is the ATL Portion
But when the ssis moves to the next file, it may change to NYC or DAL, there are about 26 files to be processed all from different regions.
Test the substring without your file variable, that uses the substring function in an expression.
Example - create a variable with the expression, then click "evaluate":
substring("ABCDEFGHIJKLMNOPQRSTUVWXYZ", 25, 2)
It will work fine.
Given that the substring function works fine, there must be something wrong with your [User::v_Filename] variable. Are you sure it is being set correctly? Perhaps you should try running BIDS with the debugger on and a breakpoint set to right after you assign the filename, and verify that it indeed is being set correctly.
I have a file variable in d3 pick basic and I am trying to figure out what file it corresponds to.
I tried the obvious thing which was to say:
print f *suppose the file variable's name is f in this case
but that didn't work, because:
SELECTION: 58[B34] in program "FILEPRINTER", Line 7: File variable used
where string expression expected.
I also tried things like:
list f *didn't compile
execute list dict f *same error
execute list f *same error
but those also did not work.
In case any one is wondering, the reason I am trying to do this in the first place is that there is a global variable that is passed up and down in the code base I am working with, but I can't find where the global variable gets its value from.
That file pointer variable is called a "file descriptor". You can't get any information from it.
You can use the file-of-files to log Write events, and after a Write is performed by the code, check to see what file was updated. The details for doing this would be a bit cumbersome. You really should rely on the Value-Add Reseller or contract with competent assistance for this.
If this is not a live end-user system, you can also modify an item getting written with some very unique text like "WHAT!FILE!IS!THIS?". Then you can do a Search-System command to search the entire account (or system) to find that text. See docs for proper use of that command.
This is probably the best option... Inject the following:
IF #USER = "CRISZ" THEN ; * substitute your user ID
READU FOO FROM F,"BLAH" ELSE
DEBUG
RELEASE F,"BLAH"
END
END
That code will stop only for one person - for everyone else it will flow as normal. When it does stop, use the LIST-LOCKS command to see which file has a read lock for item "BLAH". That's your file! Don't forget to remove and recompile the code. Note that recompiling code while users are actively using it results in aborts. It's best to do this kind of thing after hours or on a test system.
If you can't modify the code like that, diagnostics like this can be difficult. If the above suggestions don't help, I think this challenge might be beyond your personal level of experience yet and recommend you get some help.
If suggestion here Does help, please flag this as the answer. :)
According to MSDN vb.net uses this extended character set. In my experience it actually uses this:
What am I missing? Why does it say it uses the one and uses the other?
Am I doing something wrong?
Is there some sort of conversion tool to the original character set?
This behaviour is defined in the documentation of the Chr command:
The returned value depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class in the System.Globalization namespace. You can obtain ANSICodePage by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
So, the output of Chr for values greater than 127 is system-dependent. If you want reproducible results, create the desired instance of Encoding by calling Encoding.GetEncoding(String), then use Encoding.GetChars(Byte()) to convert your numeric values into characters.
If you go up one level in the chart linked in your question, you will see that they do not claim that this chart is always the output of the Chr command:
The characters that appear in Windows above 127 depend on the selected typeface.
The charts in this section show the default character set for a console application.
Your application is a WinForm application, not a console application. Even in the console, the character set used can be changed (for example, by using the chcp command), hence the word "default".
For detailed information about the encodings used in .net, I recommend the following MSDN article: Character Encoding in the .NET Framework.
The first character set is Code Page 437 (CP437), the second looks like Code Page 1252 (CP1252) also known as Windows Latin-1.
I'd guess VB.Net is simply picking up the default encoding for the PC.
How did you write all this? Because usually, when you use a output stream function, you can specify the encoding going with it.
Edit: I know this is not C#, but you can see the idea...
You'd have to set the encoding of your filestream, by doing something like this:
Setting the encoding when creating the filestream
It seems like it should be simple but as of yet I havent found a way to save the value stored in an SSIS string variable to a text file. I've looked at using the flat file destination inside of a data flow but that requires a data flow source.
Any ideas on how to do this?
Use a script task.
I just tried this. I created a File connection manager, with the connection string pointing to the file I wanted to write to. I then created a string variable containing the text to write.
I added a Script Task, specified my string variable in the Read Only Variables list, then clicked Edit Script. The script was as follows:
public void Main()
{
ConnectionManager cm = Dts.Connections["File.tmp"];
var path = cm.ConnectionString;
var textToWrite = (string)Dts.Variables["User::StringVariable"].Value;
System.IO.File.WriteAllText(path, textToWrite);
Dts.TaskResult = (int)ScriptResults.Success;
}
This worked with no problems.
Here's a little sample of some code that worked in a SQL CLR in C#. You'll need to use VB if you're on 2005 I believe. The script task also needs the read variable property set to MyVariable to make the value of your variable available to it.
// create a writer and open the file
TextWriter tw = new StreamWriter("\\\\server\\share$\\myfile.txt");
// write a line of text to the file
tw.WriteLine(Dts.Variables["MyVariable"].Value);
// close the stream
tw.Close();
All it takes is one line of code in a simple Script task. No other dependencies, such as a connection manager, are needed.
Here's what it would look like in C#:
public void Main()
{
string variableValue = Dts.Variables["TheVariable"].Value.ToString();
string outputFile = Dts.Variables["Path"].Value.ToString();
System.IO.File.WriteAllText(outputFile, variableValue);
Dts.TaskResult = (int)ScriptResults.Success;
}
Obviously the most important line here is the one containing the WriteAllText function call.
The Path variable should contain a full path + filename for the output file.
Ok, I have an answer that doesn't involve use of script task. Pick some oledb sql source you have that's simple and you have a lot of control over. Make a query that returns only one row. Then put this query in a string variable:
"select vara, ' var =: " + #[User:varIWantToSee] + "' as myvar from tablea where vara = 1"
Then in OLEDB source pick "SQL command from a variable"
For varIWantToSee make sure you initialize it with a lot characters or ssis makes a very small length for that column that it doesn't let you override. At run time varIWantToSee will get set and you can see it. Pump this all into a flat file destination and you are in business. Why do some people have to do this? Because some people need to know the value of the variables in the runtime environment, their laptop development doesn't show the variable values they need. In my case I was running this on an Azure environment that had the database accesses I needed to test. If I were microsoft I would create a task that shows the runtime variable value at that stage of the job by writing it to the ssis log file created when the package runs. If someone knows how to do that, please enlighten us.
It's possible to use a Derived Column transformation to write the value of a variable into a column. The problem is that it needs a source to drive it, and there's no stock data source you can use that just spits out a null row onto the pipeline.
So, either you repurpose a single-row source to drive the derived column transformation, or you do what another answer suggests, and do it with a Script source.
I did it the way you described. I already had a oledb connection manager defined so I used an OLE DB Source and used the SQL Command data access mode. I used a simple query:
select getdate() as dt
...just to get it out of the way. Now I know the date of my variable pull. Then I used a Derived Column Transform to make my package variables available and wrote it out to a flat file.
Elegant? No, but it gets the job done.
Lets say you don't want to mess with Script tasks and you don't have a database you can connect to just to issue a data source command like:
SELECT 'Some arbitrary text'
There are still several ways to use a Process task for something as simple as writing a line of text to a file. For example you can use PowerShell with an input variable built using the following expression:
"'"+REPLACE(#[User::Text],"'","''")+"' > '"+REPLACE(#[User::Filename],"'","''")+"'"
Notice I escaped the filename because single quotes are legal there. Also note I used '>' for redirecting which overwrites the file if it exists. If I wanted to append I'd use '>>'.
Initially I had trouble with this method when User::Text contained multiple lines. It turns out you need some extra EOL characters after your filename when a command spans lines. Like this:
"'"+REPLACE(#[User::Text],"'","''")+"' > '"+REPLACE(#[User::Filename],"'","''")+"'\r\n\r\n"
Using cmd.exe with echo is a bit more precarious but can also work in certain circumstances and has much less overhead.
P.S. I've noticed with some versions of PowerShell that StandardInputVariable content is ignored without this:
-Command -
in the Arguments box. A lone minus sign as a Command argument is 'magic' and documented at https://learn.microsoft.com/en-us/powershell/scripting/powershell.exe-command-line-help. I believe all versions of PowerShell accept this param so even if it's not required for your version you may want to include it since it shouldn't break anything and may keep your code from breaking if PowerShell is updated to a version that requires it.