4/25/2024 12:29:33 PM
slxdeveloper.com
Now Live!
|
|
| |
|
User Profile -
Jeremy Brayton
|
|
|
Jeremy Brayton
Omega HR Solutions, Inc
fiogf49gjkf0d I work for a small HR/Insurance company. I've done a number of custom plugins for our company and will always be adding more as time progresses. I intend to utilize SalesLogix to take some of the work out of the mundane tasks that automation can cover. Plus for all the cool real important utilities or bundles I make I'll release them because I don't like hogging knowledge. Knowledge was meant to be free, and SalesLogix knowledge should be no exception. You pay a ton of money for the software so you shouldn't be paying as much or more for the customizations.
|
|
| Log in to send this member a
message! |
|
|
| Jeremy Brayton's
Contributions |
|
Jeremy Brayton
has contributed
comments and
0
articles.
|
| |
| Select to view:
|
Comment: Re: The SalesLogix URL Link
fiogf49gjkf0d Application.BasicFunctions.QueMessage. It's a good place to start and honestly you're only wanting to fill in the body as any touching of the recipients raises the Outlook security prompt if done outside of this function. SalesLogix actually has a good example on how to manipulate the Outlook COM object if you need something a little more robust. It's named SLX_DoOutlook_AS and apparently hasn't changed since v6. The cool part about this code is it strips the signature and repurposes the body with the signature at the bottom, something mailto: doesn't do I believe.
Author: Jeremy Brayton - 3/23/2006
|
|
Comment: Re: How to generically invoke the edit form for a SalesLogix datagrid
fiogf49gjkf0d If I understand the problem, when you double click on the grid it will store the GetCurrentField("") value. When you change to another record and double click again, that same GetCurrentField from the first click shows up. If this is the case, comment out as much as possible until you return the correct values when you double click. Once that's been done, then add your extra code and test it from there. If you can't get it to work with the entire code, then you know that it is pulling the right value but something you're doing isn't getting it to update.
For the record, GetCurrentField("") (with nothing in the quotes) always returns the .KeyField value or at least it should. That may only be with datagrids that were done at design time and not runtime though, so I may be wrong on that. This means you could probably change your code so that you're making the exact same call twice like this:
Sub EntityListDblClick(Sender)
dim stringKeyFieldValue, stringType
stringType = Sender.GetCurrentField("TYPE")
select case stringType
case "OFFSHORE COMP."
Sender.EditView.Name="Personal:Offshore Edit"
Sender.KeyField = "OFFSHOREID"
case "TRUST COMP."
Sender.EditView.Name="Personal:Trust Info Edit"
Sender.KeyField = "TRUST_INFOID"
end select
With Sender
.Refresh
If Application.BasicFunctions.ShowViewForRecord(Left(.KeyField, Len(.KeyField) - 2), .EditView.Name, .GetCurrentField("")) = mrOK Then
.Refresh
end if
End With
End Sub
This eliminates the need to call ShowViewForRecord twice, also refreshes the grid after KeyField and EditView.Name is set just in case it's needed for the Edit to fire correctly. I changed entitylist to Sender, since that is always the datagrid who's DoubleClick event just fired. This means you can copy/paste this code into another script without modifying much at all.
Finally, I added the stringType variable to catch the GetCurrentField("type") call. This is most likely the cause of your problem as I found that sometimes if you didn't use a variable it would tend to stick with the first value called. It's been a while since that was a problem for me, so I could be wrong. Hopefully this is a good starting point or maybe it fixed the problem entirely.
Author: Jeremy Brayton - 7/29/2005
|
|
Comment: Re: Configuring SalesLogix 6.2 For Microsoft SQL 2005 Express Edition
fiogf49gjkf0d Karina:
I haven't done enough testing to verify but I believe 2005 changes some defaults when it's installed AFTER 2000, making it the database of choice for your computer. It may have triggered something at some point to make this happen. Try installing SQL Server 2000 again after 2005 to see if it puts those defaults back or you could try to dig into the documentation to see if there's some way to do this without reinstalling.
Unless there is some dire emergency requiring you to run both at the same time, I'd suggest you didn't. Test SQL Server 2005 in it's own little playground away from your production or current development sandboxes. Even though it should be able to run side by side with 2000 with little or no problems, chances are because it's beta that it's not quite at the point where it can just yet. There's little that will change from beta 2 to the RTM released in November but there probably are some kinks like this one that will have to be hammered out.
Now that I said that, this problem should be directed to the Microsoft SQL 2005 team. It may be a bug they haven't come across yet or it's possible that there's an upgrade step missed that they would know about. While SalesLogix shows the symptom of the underlying problem, it may not necessarily be the root cause. If this problem is outside of SalesLogix's domain, there's little they can do. The best you can hope for is someone else had the same idea and worked through it. If you find the answer, I'm sure everyone besides just me would like to know the answer (also answering the ITToolbox discussion group would be good as well, since a good bit of people belong to that as well)
Good luck.
Author: Jeremy Brayton - 7/8/2005
|
|
Comment: Re: Building a SalesLogix Login Screen
fiogf49gjkf0d Have you pasted the 6.2 connection string into the example code and compiled that? Ryan's sample compiles and works perfectly on 6.1 so if you were to simply change the connection string to the 6.2 format it should compile and run perfectly. Regardless the example should compile as a faulty connection string won't error until you actually try to make the connection.
There's one line that might shed a little light on why this isn't working for you:
"That all great, but something is missing. The ReadWrite password. This is a required part of the connection string if you want to read and write data via this connection."
The RWPASS isn't needed in this example because it simply enumerates the connection. If you want to actually manipulate SalesLogix data (i.e. select * from sysdba.account) you'll need to fill the RWPASS by looking at the article Ryan has already given on the subject titled "Connecting with the RWPassword From External Applications". I believe it's been updated for 6.2 (or that it hasn't changed).
This should be a good test to help narrow down where the problem is. I have a feeling RWPASS is the culprit but by plugging in the connection string to the sample code you should be able to easily verify if the string is bad or not.
Author: Jeremy Brayton - 1/25/2005
|
|
Comment: Re: Building a SalesLogix Login Screen
fiogf49gjkf0d It uses the ADO version (MDAC) that is installed with SalesLogix. I believe it's 2.6 but it may be as high as 2.8 for version 6.2. The version of ADO used doesn't really matter though as nothing has changed for a pretty long time.
Since you are connecting to the OLE DB Provider using .NET and not straight ADO, you will need to use the OleDbConnection. If you look at the function GetArrayList above the line you need is the following:
OleDbConnection conn = new OleDbConnection(connstring);
Basically if you treat ADO.NET as say version 3.0 where it is NOT backwards compatible AT ALL you'll be fine. You can't pass ADO objects to ADO.NET or vice versa. Trying to cast the GetNewConnection() return (legacy ADO) as an OleDbConnection (ADO.NET) is doing just that.
Author: Jeremy Brayton - 1/25/2005
|
|
Comment: Re: Configuring SalesLogix 6.2 For Microsoft SQL 2005 Express Edition
fiogf49gjkf0d Wow nice article. This one almost slipped by me. It's nice to know that MS finally put a GUI controller in the free side of things. It may not be Query Analyzer or a full blown Enterprise Manager, but it does the job better than those osql commands (well not better, just differently).
Hopefully SalesLogix will be working on this stuff while it's in beta so that the second it hits retail, they're both offering an upgrade to those of us who bought SQL through them, as well as just plain supporting it BEFORE it's been retail for a while. They dropped the ball on the whole Office 2003/Windows Server 2003 thing, hopefully they won't do it this time. Microsoft makes a point NOT to break much from Beta to RTM, so it's actually pretty safe to assume that what you see now is pretty much what is going to be released.
Author: Jeremy Brayton - 11/5/2004
|
|
Comment: Re: Building a SalesLogix Login Screen
fiogf49gjkf0d I've been meaning to make a Login screen to mimic the existing screens but you beat me to the punch. I also like the way the screens were split as I would typically would use a Client login type of approach since it mimics the Administrator or Architect.
I was getting an error when I was trying to view the list of aliases on a remote machine, but the error has since went away. I don't know if it was me installing #Develop that did it, or that the person is no longer in SalesLogix but I'm going to try and run it down to figure out if it's a problem or not. Personally I'd rather fix your login screens than to try to make my own and run down it's own problems and pitfalls.
Thanks for the article. It's definately a keeper.
Author: Jeremy Brayton - 9/22/2004
|
|
Comment: Re: How to generically invoke the edit form for a SalesLogix datagrid
fiogf49gjkf0d In Service Pack 2 using the function I pasted doesn't work. Period. I believe at one time (pre SP2) it worked but now it doesn't.
What it does is kind of weird. It will load the EditView of the grid in question. The form will be blank and appear EXACTLY as it does when you select Add. The funny part is that the data doesn't save at ALL. You fill in the record, click OK and go to look for the record. You won't find any new record. I even went as far as to populate the primary key field programmatically (using OnChange event) and it STILL didn't save the record.
From appearances it looks like it works fine. It shows "Inserting (Form Caption)" instead of "Editing (Form Caption)" but the code behind the call doesn't save the record like it should. Maybe this is a bug? I could have swore it worked before SP2 but I may not have tested it fully. I do know I tested the crap out of it later trying to make it save but I couldn't get it to work.
Ryan if you do have this working I'd be anxious to know which version of SalesLogix you're using. A proof of concept bundle of both the edit and add functions would be cool. I made one up but because I couldn't get the add working correctly I scrapped it and I'm starting to wish I hadn't.
Author: Jeremy Brayton - 8/17/2004
|
|
Comment: Re: SalesLogix 6.1 Procedures
fiogf49gjkf0d Username and Password: Supplied by you. If you had a way externally to see even just a simple list of users guess what? Major security flaw. Someone from this list could generate a brute force cracker and gain access to your database eventually. I don't even think SalesLogix has a way of logging who tries to login to see if such a brute force entry is tried. It's highly unlikely anyone would want to do this but I believe because it is possible (even brute forcing usernames AND passwords) there should be some sort of auditing mechanism to help notice anything like this. SalesLogix was smart on making sure no one can see a list of users outside of the database without a valid way into the system.
With windows authentication in 6.2, there'll be an increased possible security threat. Say someone gained access to even a restricted user. They may not be able to uninstall programs but they can login to saleslogix, call "delete from account", "delete from contact", "delete from opportunity" in SQL and wipe your database clean unless there's some sort of restrictions on what can be deleted and by whom.
1. Is your machine a part of a domain? When you set up your connection using the ... on the login screen, do you see any other computers when you click the drop down? If not then that's your answer. It most likely only shows what is in that drop down. Why other machines won't show up is a hard thing to troubleshoot based on just the information you provided, there's a host of reasons.
2. The connection information is stored in the registry in lovely little keys and values. The "Connection Manager" registry stuff is stored here: HKEY_CURRENT_USER\Software\SalesLogix\ADOLogin. Under it is 10 connection keys that give the different database definitions you set up. I believe there's also some other keys that help, but this is the main one I know of.
Using the SalesLogix procedures does all the work of decyphering the many registry keys and values and places them in a lovely to use function. You could code your own way of decyphering the registry but it's way too much work when all of it's already been done for you.
Author: Jeremy Brayton - 6/16/2004
|
|
Comment: Re: Consuming SalesLogix Data via RSS
fiogf49gjkf0d Awesome. I love RSS a little too much (tons of feeds subscribed, so many I can barely keep up that it almost becomes a full time job reading them) and this is something else I really don't need to deal with but it opens up a world of possibilities.
SalesLogix should pick up on this and use it for some alert features (free possibly? finally?) but if they won't then someone like me can using this method.
Anyone who can, should use RSS as much as possible because it keeps only the important information at your fingertips. You don't have to weed through tons of useless information for those golden nuggets of information goodness. Sweet. Thanks again for the great article
-Jeremy
Author: Jeremy Brayton - 4/15/2004
|
|
Comment: Re: How to generically invoke the edit form for a SalesLogix datagrid
fiogf49gjkf0d I did some testing for the ITtoolbox SalesLogix group and found that if you omit the RecordID you simulate the old DBGridAddValue function.
Try this:
Sub DataGridAddRow(Grid)
With Grid
If Application.BasicFunctions.ShowViewForRecord(Left(.KeyField, Len(.KeyField) - 2), .EditView.Name, "") = mrOK Then
.Refresh
End If
End With
End Sub
I forgot the ModalResult value and usually didn't refresh. The GUI seemed to refresh for me but I may not have noticed it. Thanks again for the tips
Author: Jeremy Brayton - 3/24/2004
|
|
Comment: Re: SalesLogix 6.1 Procedures
fiogf49gjkf0d This may be a suggestion for a new article or a series of new articles but I have some basic questions:
1) What procedures can be used internally in SalesLogix customizations? (ie do I need to call slx_SetGlobalID(accountid) when doing a SQL INSERT via scripting?)
2) What procedures are necessary to completely setup synchronization logging? (first call slx_SetLogging(ON), slx_SetGlobalID, DML statement, LogSendFileAttachment, when done call slx_CycleLogFile())
3) What procedures can be used via external customizations or are necessary for basic use?
I understand the procedures very well I just don't always understand where they would serve the best purpose. I understand things like slx_GetServerList would be useful in a 3rd party app where you need to specify a specific SalesLogix server to work from but I don't understand much more than that. I've never understood the need for SetGlobalID in pre 6.x nor do I understand the need for slx_SetGlobalID now and little things like that keep me chasing my tail when problems arise. A table giving the 'best uses' of each of the procedures would be ideal, or maybe individual articles which serve as a framework for developing certain kinds of internal or external customizations to SalesLogix.
Thanks
Jeremy
Author: Jeremy Brayton - 1/26/2004
|
|
Comment: Re: Question to the Author
fiogf49gjkf0d This may be a late entry but I think it might be useful.
In the resynctabledefs they have the key fields (id values) stored for every table. Since these are ONLY the id fields like accountid, custom_tableid, etc you could simply run a query to get the id fields from this table and check the entire recordset against these id fields to see if they match.
To look at the id fields for a table run the query: "select keyfield from resynctabledefs where tablename = table". If it's run on say the account table it produces a line with the accountid. The only problem here is if I run a query on a custom table with accountid and custom_tableid as the id fields only custom_tableid shows up in this query.
From there you could run another query: "select fromfield from joindata where fromtable = table" which would give you the account id field in your custom table if it's a one to many table. If it's a one to one relationship the fromfield here will equal the keyfield in resynctabledefs so you could add a check for this.
Anyways I believe through a join or a careful select statement one could produce both id fields at one time rather than perform 2 queries. This would be the most ideal but since they are select statements and you can read the returns and close the connections we aren't talking about a lot of used resources.
I could be wrong in my logic but this should work for now until SalesLogix changes the way it internally stores data. There's probably a bunch of other ways to do the same thing programmatically but I just happened to think of this one as the easiest in my head. If you have another method by all means share as I want to handle as much of this programmatically as possible.
Author: Jeremy Brayton - 10/24/2003
|
|
|
|
|
|
|
|