Patrick,

If you don't have remote users that synchronize, you can use the stored procedure I provided here http://customerfx.com/pages/crmdeveloper/2013/12/23/sql-stored-procedure-to-create-saleslogix-table-id-values.aspx

This will allow you to create SLX table ID values from direct SQL and can be used where ever you want.

Ryan

Jason's follow-up article to this one is posted here http://www.slxdeveloper.com/page.aspx?action=viewarticle&articleid=107

Sarbello,

The SLX procedures are not database procedures. Instead they are implemented only in the SLX OLEDB Provider. To use the SalesLogix function slx_dbids to create table ID values (which the functions outlined in this article use) the SalesLogix OLEDB Provider must be installed and a valid SLX connection string must be used. Although the functions in this article exist in SQL, they are merely calling the slx_dbids function wil is internal to the SLX OLEDB Provider.

Ryan

Hi Adam,

I do not and don't plan on making one since it would require a full rewrite as all of this code was based on BDE (for SLX versions prior to v6). Sorry 

Ryan

Hi Gregory,

This utility was built long ago for a version of SalesLogix that worked quite differently than recent versions. It will only work with versions previous to SLX version 6 (basically from v1 to v5).

Hi Paty,

The point of integrated security is that you don't need the user's login name and password. There's no way to get it from the connection since you're not providing it to the connection. Make sense?

-Ryan

Guy,

The ShowViewForRecord method doesn't have any ties to a grid at all, so it shouldn't/won't matter what table the grid is bound to since ShowViewForRecord doesn't have anything to do with the grid, or even know about it. It all depends on what the base table of the data bound form is and what table value you pass to ShowViewForRecord.

Does that make sense?

string result = t.LoadStaging("200701");

Application.Managed.Run ext, args

myResult = Application.Managed.Run(ext, args)