Register   |  Login
    Edit Task
    New Ticket Existing and Public Tickets   
    Ticket:  220  Created: 12/10/2012 12:00 AM
    Status:    Assigned:      
    Lean Application / Version:
    Priority:       Due Date:  
    Name:   CommerceHub    
    Email:   -
    Phone:    Estimate Hours:  
      Start:    Complete:  

    Visible to Requestor Comment User Time
    Select Problem is fixed in version 2.8.870! I'd be curious to know what the root cause turned out to be, but this ticket can finally be closed! CommerceHub 12/9/2013 12:00:00 AM
    Select Please can we ask if this remains a problem in 2.6 beta? Thank you Lean Software 5/29/2013 12:00:00 AM
    Select The problem still exists in version 2.6.770b as described in the recent note below from 5/15 regarding version 2.6.276b. Requestor 5/29/2013 12:00:00 AM
    Select I wanted to report some progress on this in beta version 2.6.276b. When I go into Task Configuration for a Task that uses an ODBC connection, and go to the Worksheet columns / SQL tab, the columns that are shown are no longer changed to a different table than what was originally configured. But the name of the table in the dropdown box above is still incorrect. It used to be that the column configurations would also be changed to reflect the columns of the incorrect table. The incorrect table that is shown in the dropdown box is consistent. It is always the last table of the first 'schema' in the DB. For example, in this DB we have three schemas: config dbo odd The incorrect table that is chosen is the lsst of the tables in 'config'. CommerceHub 5/15/2013 12:00:00 AM
    Select Test to check ticket active on new account Lean Software 3/11/2013 12:00:00 AM
    Select Problem still exists in version 2.5.268. I think there was some misunderstanding of my last post on this issue. I wasn't saying that it had been resolved, only providing some additional observations. CommerceHub 2/12/2013 12:00:00 AM
    Select Now that I have had success with my first Task that uses parameterized input to a non-trusted connection string I can report that this problem does not occur using that connection method. That doesn't mean that it isn't a problem any more, only that the problem may be specific to ODBC access. The ODBC access approach is still what is needed for my analyst's work. I need to do the task configurations and put them into a network library that all analysts can access. They need to be able have the tasks access their personal DB's without having to touch the Task configuration or enter a lot of parameters every time they want to work on something. Aside from this one problem, using ODBC as a workstation level abstraction that let's them independently manage what DB the task connects to has been working perfectly to meet that need. CommerceHub 2/7/2013 12:00:00 AM
    Select Problem still present in version 2.5.183. Same task configuration file as attached to ticket 246 CommerceHub 2/6/2013 12:00:00 AM
    Select We have tried as suggested, setting connection to DSN : Provider=MSDASQL.1;Persist Security Info=False;Data Source=Test SQL Server DSN; Then changing the database name in ODBC manager, but for us the selected table table was remembered/set correctly. The task XML sent to us also looks OK. Troubled/baffled by this outstanding problem. Lean Software 1/11/2013 12:00:00 AM
    Select In case it helps, here are the exact steps I go through in Windows (XP) to create the ODBC DSN: • In Windows, got to: Control Panel / Administrative Tools / Data Source (ODBC) • On the UserDSN tab choose “Add”. Choose the SQL Server Native Client 10.0 Driver from the bottom of the list, then click Finish. • Now fill in the configuration blanks: - The name must be “MetaData db”. - Give it a description of “ODBC connection for updating metadata” - Identify the SQL Server instance where your metdata db resides. • Click Next, and Next again to get to the page that begins with the check box “Change the default database to:”. - Check the checkbox, then choose your db from the dropdown box. • Click Next, and then Finish to get to the box where you can test your data source. If the test is successful, click OK to exit the ODBC Data Source Administrator tool. ====================================== Data access for initial load of the spreadsheet, Validate and Send have all been working perfectly using this kind of data source. The only problem that I have encountered is this one issue in Task Configuration. I don't know what else to suggest to reproduce the problem. CommerceHub 1/11/2013 12:00:00 AM
    Select Interesting observation: I can take the task configuration that I sent you and put it in a folder with version 2.1.11 of the application and the problem does not occur. The next version that I have here is 2.2.287b and the problem does occur there. So the problem seems to have been introduced in the move from 2.1 to 2.2 CommerceHub 1/11/2013 12:00:00 AM
    Select Sorry - got the version number wrong in my last post. The last version that I have where the problem does NOT occur is 2.1.114b CommerceHub 1/11/2013 12:00:00 AM
    Select Many thanks for the further info, will try again this end to reproduce the problem. Lean Software 1/11/2013 12:00:00 AM
    Select Doug, we will be working on this ticket today (Thursday 10th jan). We are running tests using a DSN connection - as I think that is where the problem lies. If there is any further information / insight that would be great. Do I take it that the destination table is not remembered even if you use a direct connection e.g. Provider SQL Native client 11. Lean Software 1/10/2013 12:00:00 AM
    Select All of my current piloting work is being done with User DSN's defined under ODBC because that is the most convenient way to have some indirection between the task configuration and the db connection specifics. I dictate the DSN name in the task configuration. This allows the task configuration to be used by multiple users without locking the user into any particular DB server or datatbase or requiring the user to enter DB related parameters at run time. As long as the user creates a User DSN through the ODBC utility resource with the appropriate name, they can configure that resource to be whatever they want and change it to point somewhere else as necessary. All database access can occur without any prompts or direction from the user at run time. If there is another way to approach this that yeilds the same results I could change it, but I don't want to complicate the run time behavior. The DSN's are being configured with the SQL Native client 10.0 Provider. That is the most current Provider available on our workstations when setting up an ODBC DSN. CommerceHub 1/10/2013 12:00:00 AM
    Select Thank you Doug, can I ask if you have the same problem with 2.3.97? Lean Software 1/10/2013 12:00:00 AM
    Select ok i am going to simulate your setup by changing odbc database as you describe and see if i can reproduce the problem. Lean Software 1/10/2013 12:00:00 AM
    Select Unresolved, requires investigation Lean Software 1/3/2013 12:00:00 AM
    Select May have a clue on this one. Because I am authoring Task Configurations for use by others, I didn't want any machine specific parameters embedded in the configuration. So I instruct the users to set up ODBC data sources on their machines with a specific name that matches the ODBC data source that I have built into the task configuration. That gives them the freedom to name their database whatever they want, and to set it up on whatever server they need to. But I found that the users were having problems because when I saved the initial Task Configuration it captured a couple machine specific parameters - WSID and Database name - and that was causing problems for the users because it did not match to their environments. I found that if I manually removed the following from the end of the ConnectionString in the Task Configuration XML that everything worked very nicely: WSID=????;DATABASE=?????; Except maybe that is the cause of this problem? I don't want the Task Configuration XML to be machine specific. And everything else seems to work fine without that being at the end of the connection string. Just wanted to call that out in case it is the cause. CommerceHub 12/12/2012 12:00:00 AM
    Select Ah I see, that is interesting. When using the DataLink dialogue if you use the 'Use data source name' option and select from the drop down, it should in theory only insert a simple connection string like this one: "Provider=MSDASQL.1;Persist Security Info=False;Data Source=Test SQL Server DSN" It should not have any other info then in the connection string. Richard Lean Software 12/12/2012 12:00:00 AM
    Select Since version 2.2.287b, when I go into task configuration for an existing task and go to the Worksheet Columns / SQL tab, the DB table columns that are shown are not for the table that the task was configured for. It appears to be for the table that would come first in a list of objects for the db upon first opening a connection. But the work columns that were previously configured for the task are all present and appear correct. If I manually choose the correct table from the dropdown list, then all of my previous configuration settings for the columns of that table are magically remembered. But if I neglect to do this and save my configuration, then all of that is lost and I end up with the columns of the incorrect table. Requestor 12/10/2012 12:00:00 AM


    Skip Navigation Links.
    Bug report
    Expand DatabaseDatabase
    Feature request
    Help request