08-30-2012 01:28 PM
I am new to SalesLogix and am In an environment where many custom tables and screens have been developed without a great deal of change management or documentation. To cleanup, we need to know how the fields and tables map to each other. Are there any developer tools that produce some sort of design synopsis?
08-30-2012 02:45 PM
A - "joins" are all in the JoinData table in SLX
B - OOTB table/field info depends on the original version of SLX your system started with and which SP's and HF's were added over time.
There's a sort of "master" to all of this you can refer to called the SalesLogix DB Help (.chm) file.
I've done a ton of SLX DB analysis over all versions of Slx (from v2.x thru the current v7.5.4 as well as the v8.0 in beta) and could do one for you saving you a lot of time/effort... and it will not take alot of time ;-)
Give me a direct call (+1 508 809 9513) and we can discuss it.
09-12-2012 02:53 AM
you could use a tool like visio to connect to the SalesLogix DB through the SLX OLE DB Provider and view the relationships between the tables, obviously JOINDATA contains all the table relationships that are stored from the OOTB tables as well as the custom tables that you add.
You can then create a visio database diagram to have it printed on the plotter.
09-12-2012 05:03 AM
At one time there was such a document (produced by tech pubs). However, it was so big and complicated it took (almost) 1/4 inch of 8.5x11 paper to print it.. and then you would have to "assemble it".. or you could get a large printout from SalesLogix.
Now which wall do I want tp paper w/my diagram?... humm..
Along w/user manuals, it became obsolete.
As you point out, the SQL server db has no knowledge of the (table) relationships and one woudl have to manually create the relationships in the diagram in Visio. Not a good use of time and energy.
09-13-2012 04:17 PM
Actually JOINDATA does not contain all of the relationships.....(don't EVER forget that there is a Web side to the equation)......and TableName + ID = Table.KeyId is wrong about 5% of the time.... and fields that end with ID or =CreateUser are ID fields are wrong a ton of times.....both ways (Product.ActualId, Product.Vendor, Product.Supplier, History.CompletedUser.....).....
John Hedges had a the Rosetta Stone for Legacy Forms databindings.....but stated that the object hierarchy\embedding made it very difficult to get a list of ControlName.DataBinding field.....
09-13-2012 04:23 PM
You are correct.. in fact, the joindata table really means nothing to the web side since it has it's own "relationship" setup that is burried in the XML code.. in the VFS ;-)