http://www.sqlmag.com/authors/author/author/5070033/rsscomment/5070033en-USFri, 25 May 2012 10:42:41 GMTFri, 25 May 2012 10:42:41 GMThttp://www.sqlmag.com/article/task-scheduling/a-recipe-for-replacing-session-variables#commentsAnchorWed, 09 Jan 2008 13:32:22 GMT
Excellent article. I’ve begun using this on several projects and am glad to be free of Session Variables. In case anyone needs a good routine to create a GUID, here’s one that I found. Function createGuid() Set TypeLib = Server.CreateObject("Scriptlet.TypeLib") tg = TypeLib.Guid createGuid = left(tg, len(tg)-2) createGuid = Replace(createGuid,"{","") createGuid = Replace(createGuid,"}","") Set TypeLib = Nothing End Function]]>SeanWed, 09 Jan 2008 13:32:22 GMThttp://www.sqlmag.com/article/task-scheduling/a-recipe-for-replacing-session-variables#commentsAnchorhttp://www.sqlmag.com/article/tsql3/automate-date-time-conversions#commentsAnchorMon, 14 May 2007 12:39:08 GMT
Setting ansi_nulls off may cause some errors for those using 2005. When the ansi_nulls is not specified, by default, the compiler will compile this with Ansi_nulls ON. As your code doesn’t care whether it is on or off (ie no "if @var=null" statement exists), I’m curious as to why you specify it as off.]]>JAMESMon, 14 May 2007 12:39:08 GMThttp://www.sqlmag.com/article/tsql3/automate-date-time-conversions#commentsAnchorhttp://www.sqlmag.com/article/tsql3/automate-date-time-conversions#commentsAnchorSun, 04 Mar 2007 22:31:10 GMT
This is definitely useful and I will use this.]]>GARYSun, 04 Mar 2007 22:31:10 GMThttp://www.sqlmag.com/article/tsql3/automate-date-time-conversions#commentsAnchorhttp://www.sqlmag.com/article/task-scheduling/a-recipe-for-replacing-session-variables#commentsAnchorThu, 25 Jan 2007 09:28:38 GMT
More on Storing Session State I read Susan Perschke’s article "A Recipe for Replacing Session Variables" (March 2006, InstantDoc ID 49114), which describes using a back-end SQL Server database to store session state, and I agree that this is an excellent solution. I’ve been using this technique for a number of years now. The only spin I’ve put on it is that I save the session information in the form of an XML document. The back-end SQL table has three columns: SessionID (randomly generated), Session XML (the XML document), and SessionExpires, a date/time field indicating when to purge the table row. This date-time column is updated (one day is added) on each visit to the Web server. This aids in maintaining the table size during database maintenance procedures. I’ve created a class library called, oddly enough, SessionState. This library is written in .NET and incorporates, among others, the System.XML namespace and contains functions to Add, Update, Delete elements and attributes; Create, Clear, Delete session objects; and Retrieve and Save the current XML document. It basically wraps the functionality of System.XML into a small set of user-friendly functions for Document Object Model manipulation, and wraps System.Data for persistence. Using this technique, I’ve virtually eliminated having to pass parameters via URL or hidden form fields. The technique has never failed and has simplified our development efforts. It also has opened the door to true load balancing in our Web farm. One serendipitous use of this approach is that a customer support person can "jump into" another user’s session simply by opening a support Web page and selecting the appropriate session from a list of saved sessions currently in the back-end SQL table. The support person can then reproduce any erroneous behavior that the user may be reporting. I knew I couldn’t be the only person doing this. It’s just that good. —Michael Lopez]]>DianaThu, 25 Jan 2007 09:28:38 GMThttp://www.sqlmag.com/article/task-scheduling/a-recipe-for-replacing-session-variables#commentsAnchorhttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorWed, 10 Jan 2007 07:06:29 GMT
Hello Susan, I tested de code in listing 7 and I think that I found a little mistake. When GUID exists, code in listing 7 call gen_new_guid() (line 21) function again, I suppose that in this line the correct function is upd_guid(). I am correct ?]]>JoseWed, 10 Jan 2007 07:06:29 GMThttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorhttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorMon, 01 Jan 2007 23:14:20 GMT
Internet Marketing is obviously not one of your expertise’s or you know exactly what I am talking about and have some stakes in a Paid-Search Marketing Agency. Session IDs passed in the URL create issues for search engines. They try to determine them and try to filter them out, but that does not always work and sometimes stop SE simply to index your site if they decide that it is not worth the hassle to figure out the "mess" created by changing urls that return an exact duplicate of another page with a "different" url. I have not even started to talk about other problems because of this, because they all do not matter if your site is virtually not existent in the Search Index. The problem described does not just affect the Amazons (who is optimized btw. and modified to prevent duplicates from being indexed, but to explain what they did is beyond this issue here). Any Site that is Database driven (dynamic content) is affected. Developers ignoring this will not make friends with the marketing department and execs or owners once they find out why their website is nowhere to be found in the organic or free results of the search engines where 80+% of the users still decide to click through. I can only suggest to anybody to be very careful with the implementation of this solution as is without doing some quick research on Search Engine Optimization (SEO) Basics or your company might has to pay a hefty price tag afterwards to "fix" the problems you, the developer, created.]]>CARSTENMon, 01 Jan 2007 23:14:20 GMThttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorhttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorWed, 27 Dec 2006 08:55:57 GMT
Sent: Wednesday, December 27, 2006 8:05 AM Subject: Re: SQL Mag Article 12/2006 - Cookie-Less Session Manager Hi Carsten, Thanks for taking the time to write. The concepts presented in the article would apply to areas of a site that require user tracking, which can vary significantly depending upon the application. There are trade offs with every method. Developers must weigh the advantages and disadvantages of each. You are correct that a check of the IP and User Agent is not failsafe, because it is not unique, but I consider it a good method for small to midsize operations, which comprise the majority of websites. Assuming you expire the IP / User Agent pair frequently, the statistical chances of duplication for the average site ~ at a given point in time ~ are extremely minimal unles you are Google or Amazon. In that event you have a $1M annual budget for web development with the flexibility to redirect for every contingency. As to organic listings, in my opinion these are getting less and less reliable as search engines rely on paid clicks to drive their stock prices. Paid advertising is becoming de rigeur for most operations and should be factored as a cost of doing business. We have successfully driven traffic to our customers’ sites using a very small advertising budget. In any event, I very much appreciate your feedback on the article. Have a Happy New Year. Regards, Susan]]>DianaWed, 27 Dec 2006 08:55:57 GMThttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorhttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorWed, 27 Dec 2006 08:50:21 GMT
----- Original Message ----- From: Carsten Cumbrowski Subject: SQL Mag Article 12/2006 - Cookie-Less Session Manager Hello Susan, I saw your Cookie-Less Session Manager Article in SQL Magazine 12/2006. I developed myself various enterprise ecommerce solutions and the shopping cart basically works similar how you described it in the article. I usually generate the ID a bit different, but that is not the reason why I am writing you. I also happen to be an Internet Marketer who knows quite a bit about well, marketing a website on the internet. One important aspect of internet marketing are search engines. Even the big brands can not ignore the importance of being visible there, not only in the sponsored results via Pay-Per-Click Ads, but also in the organic listings. If a developer implements your cookie-less solution into a e-commerce solution, then can the merchant who is using it prepare himself to pay a very high bill to a Search Engine Optimization Company and the Web Development Company again. The merchants often realize the issue very late in the game once they got the idea to setup some web analytics and notice that their search engine traffic is very low or in some cases even non-existent. The Cookie-Less session passed in the url would be especially a problem if you assign the Idea to every visitor who is browsing the site without even having something added to the shopping cart. You only end of with minor problems if the catalog can be browsed without having a session variable passed along in the URL and only gets created and passed along once the user adds a product to his shopping cart. If every visitor gets right away a session ID then you are risking to get a major "Duplicate Content" issue with some or all search engines. search engines try to work around those sessions and detect them, but their detection does not always work properly. The value in the URL other issues too which I will not elaborate further at this point. Also from a security point of view do I see issues with it. Your check of the IP and User Agent is not fail-safe and gets more of an potential issue the larger the site is and the higher the traffic. High traffic websites have a lot of hits from different people with the same IP (proxy) and same user agent (there are not very much variations out there). Regardless if they do or not is it something you should avoid as much as you can to not put yourself into the position that you need to add a lot of code just that search engines will be able to crawl a site properly. There are different options available, but none is simple or cheap. It could also happen (worst case) that a change of code will not do any good anymore, because of a permanent penalty or ban of the domain by search engines. It can take a lot of time and efforts to get the penalties removed and the site re-crawled again. You can find more resources to the issue of "duplicate content" here http://www.cumbrowski.com/CarstenC/seo_duplicate_content_issues.asp The resources go far beyond sessions passed in URLs, but is one of the most common ones that causes problems for webmasters. Learning about the problem in general does not hurt anyway, because other mistakes in site design can create the same effect as well. I hope this makes sense to you. If you have any questions, let me know. Merry Christmas!]]>DianaWed, 27 Dec 2006 08:50:21 GMThttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorhttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchorTue, 05 Dec 2006 11:15:26 GMT
Excellent article! I will try to implement this on our site.]]>BERNARDTue, 05 Dec 2006 11:15:26 GMThttp://www.sqlmag.com/article/stored-procedures/cookies-crumbling-#commentsAnchor