| eeaglehouse |
| Member |
| Ed Eaglehouse |
| Akron, OH |
| Applications Developer |
|
| Male |
|
| Friday, October 7, 2011 |
| Friday, August 18, 2023 6:20:26 PM |
11
[0.06% of all post / 0.00 posts per day] |
|
|
After 11 years, this behavior still hasn't been fixed or documented. I ran into this problem again and found my own post. The misbehavior of logical functions must really be added to the documentation because they are not working as currently documented!
|
that wrote:eeaglehouse wrote:Whenever I make a change to a single mapping or library function, I have to manually edit about 20 files on average to fix the cursed connection string, turning even a trivial 5-minute change into something taking 30 minutes or more.
As far as I remember, the connection strings only appear in the small wrapper class that calls the actual mapping - so maybe it's more convenient for you to just replace that whole file with your own after generating the code?
That's only the initial call to the mapping. If you have functions that access the database, the generated source code for the connection string are in each function module, too.
Actually, I think I may have stumbled onto a workaround. Instead of replacing the entire connection string assignment statement, I have inserted a parameter (a function call to another module, in my case) and a dummy assignment in front of the connection string. The dummy assignment preserves the syntax of the original, innappropriate assignment so the compiler doesn't complain, but I still get my own connection string at runtime.
So the original statement lines:
Code: conn.ConnectionString = "generated, inappropriate, confusing, huge, and useless"
+ " connection string";
Become:
Code: conn.ConnectionString = Global.GetMyRuntimeConnectionString(); object ignored = "generated, inappropriate, confusing, huge, and useless"
+ "connection string";
Sometimes rants release enough pressure to come up with a more creative fix. It's a pity that it had to come to that.
|
Update: Altova has ignored this problem for years. With MapForce 2018 and later, they have made the problem even worse. Not only is the connection string hard-coded, but it generates the connection string constant over multiple source lines. That makes it nearly impossible to do a simple search & replace. Without advanced editing - the kind that can parse C# or whatever language you're generating - editing must be done manually and cannot be automated.
Whenever I make a change to a single mapping or library function, I have to manually edit about 20 files on average to fix the cursed connection string, turning even a trivial 5-minute change into something taking 30 minutes or more. This is a giant stain on an otherwise decent product.
Using a Global Resource doesn't help either. The connection wizard tries to validate to a live database when saving, so it prevents you from creating a simple dummy connection string that would be easy to replace.
For the record, I am no newbie as I'm labeled in this forum. I have been using MapForce regularly for over five years and still gotten no satisfaction with Altova on this issue. This is a design flaw they haven't even tried to fix.
The extreme difficulty of changing or parameterizing connection strings when using generated code is and has always been a major pain point when using MapForce.
|
Is there a way in MapForce to add the Code:[DebuggerStepThrough] or any other attributes to the classes generated in C#? Failing that, is there a way to make it generate classes so i can add the attributes myself and keep them from being overwritten by regeneration?
The reason I ask is that, during debugging, some exceptions are being thrown in some inefficient Altova functions. It slows down debugging my own code because I have to click through the exception every time it happens. For example, the function throws an exception when the input string is shorter than the number of characters requested. The code catches the exception instead of checking the arguments. I would like to apply the attribute to the generated classes so the debugger will skip over Altova-generated functions.
--Ed Eaglehouse
|
vlad wrote:Did you try to use Global Resources instead of direct database connection? They will allow to switch a destination with a single combo-box.
That works only until you generate code. Then the connection strings are hard-coded.
|
To add some clarification, you can create mappings and user-defined functions using a shared global resource, when the same connection string will be used. Before you generate code for the project, you can select the global resource the mapping is generated against. This hard-codes the connection string for the selected global resource into the generated code. Code generated for user-defined functions have the same problem but the solution is the same.
Global resources do not give you the ability to change a connection string at runtime.
To select a connection string at runtime, you must edit the generated code to replace the connection string with what you want. In my case, I was using C# and created a global object with a connection string property that I shared with all my compiled mappings. I replaced all hard-coded connection strings with a call to my connection string property, which I populated from a connection string resource in my configuration file.
Another possibility is replacing the hard-coded connection string with a direct call to a configuration connection string resource. This would have worked equally well in my situation, but carries the overhead of accessing the configuration file for every new connection, which can happen hundreds of times during a typical mapping.
Here is an example of generated code that has to be changed. Note that the new System.Data.OleDb.OleDbConnection(...) pattern is used throughout MapForce-generated code, so a Find-and-Replace-in-Files from a text editor or VisualStudio for the files in your MapForce project works well here.
Code: string connectionString = "Provider=SQLNCLI11; Data Source=mydbinstance; User ID=mylogin;Initial Catalog=mydb;Integrated Security=\"\";Persist Security Info=False;Initial File Name=\"\";Server SPN=\"\";";
System.Data.IDbConnection conn = new System.Data.OleDb.OleDbConnection( connectionString );
conn.Open();
My connection string is accessed through MyProject.GlobalConnections.MyDBConnectionString. The edited code looks like the following.
Code: //string connectionString = "Provider=SQLNCLI11; Data Source=mydbinstance; User ID=mylogin;Initial Catalog=mydb;Integrated Security=\"\";Persist Security Info=False;Initial File Name=\"\";Server SPN=\"\";";
System.Data.IDbConnection conn = new System.Data.OleDb.OleDbConnection( MyProject.GlobalConnections.MyDBConnectionString );
conn.Open();
The original connection string assignment is commented out to avoid a compiler warning. Leaving it alone doesn't hurt anything.
|
I have a project in development that will require processing X12 version 6040 files. MapForce 2014 SP1 currently has configurations available only up to 6020, which was the latest standard from February 2009.
Does anyone know how I can get configuration files for later releases, specifically 6040?
|
|
After spending time playing with different inputs and other functions, that is what I suspected. Thanks for the confirmation.
|
The functions you are looking for are organized under lang.string functions.
You may be seeing only the core.string functions:
char-from-code
code-from-char
concat
contains
normalize-space
starts-with
string-length
substring
substring-after
substring-before
tokenize
tokenize-by-length
tokenize-regexp
translate
As Vlad instructed, you need the language-specific library functions.
|
My logical functions are not behaving as documented because they are not always returning a true or false result.
For example, I have an "equal" function mapping two inputs, one returning an integer value and the other returning a null value. According to the documentation, "equal" says "Result is true if a is equal b, otherwise false", but it is really returning null. I expected it to return false, since the two values are not equal.
I get a similar result from a "logical-or". It is also returning null.
Is this a bug or is it a documentation problem?
|
|
