Forum Moderators: open
I'm finally delving into the realm of VB scripting, and I'd like to understand how I can develope objects to access and retrieve stored procedure results, in my ASP pages.
What I'm trying to do is to create an alternate power search module for our shopping cart system, as our current one stinks to no end.
Assuming that I already have the stored procedure in place in SQL, and I have intermediate knowledge of VB scripting, I have a few doubts:
1) Would I need to pass login/password into the component object before I can do this?
Set objSearchResult = Server.CreateObject("boMySearchCodes.grabMyStuff")
searchrResult = objSearchResult.passinfo(searchterm)
2) Does the component return has to be hard coded with how many results to be expected? For example let's say the stored procedure returns n rows, and 6 columns per row. If I suddently change the stored procedure to return 7 columns per result, would I crash the current Object and causes our shopping cart software to throw errors left and right?
I would really like to get into VB scripting, as our company will be relying more and more on .NET technologies as time goes by. I've read up on the following websites regarding my problems, but:
1) MSDN: STEEP learning curve! I got lost after reading the first few chapters.
2) 15seconds and 4GuysFromRolla: Horrible navigation, and search structures. And their articles on VB scriptings are too similar to eachother, and assumes you are a pro on DLL decompiling (I'm just exaggerating)
3) various searches on google: results in amazon books, or courses, or windowssitepro $XXXX per month access to their articles.
Why I do not take courses, are because I self-taught all my programming skills(PHP,Perl,DOM) and I really believe in teaching myself VB and SQL.
Sorry for my long winded posts. If anyone can also suggest on some beginner's articles specifically in dealing with accessing databases with COM, in ASP, that would be great...
Search is my friend
Alan
If you need to use COM then it just adds another layer of complexity to the mix. For your database connections you'll either have to hard code them into your Dll, read them from some ini, configuration file, or registry, or pass them in as parameters in each method.
You component will just return the recordset from the database. It doesn't matter if you change the column return size, changing the parameters on the sproc would require a recomile of the COM object.
I would suggest picking up a book on ASP and learn how to access the database from there before you tackle throwing COM in there.
I would really like to get into VB scripting, as our company will be relying more and more on .NET technologies.
COM+ is not a .NET technology. Why do you want to learn COM+ if your company will be using .NET?
The reason I need to do this, is because (I'm not sure if I am allowed to disclose the software name in this forum) our system is using an integrated 'all-in-one' small business management and accounting software. However our business is heavy web-related,and that particular software is severely lacking in feature that fulfills our company's needs. The E-commerce feature of that software uses ASP, with all SQL calls being made by COM (Server.CreateObject) methods.
Second reason I'd like to follow the approach of adding/modifying the DLLs, is because I figured I'm better off modifying a section of the codes, rather than re-inventing the wheel. As for example to display a single product for the store, it uses 3 stored procedure calls(I traced), misc user functions, uses 3 temporary tables, and spans across 12 tables(kid you not).
In response to TheNige:
Do you have to do this in COM? You can access the database right from your ASP page using VBScriptI'm actually very pro with VBscripting it via ASP page, but as each page already tunneled a connection to the database, I was thinking it maybe less resource to re-use that connection, rather than opening it via a new ADODB.Connection.
I have heard that it is very resource intensive to do it the ADODB.Connection way.
I do have it in some of my pages though, as a temporary fix to some features we severely need, but so far I'm only doing selects, as I'm afraid to screw up the database with inserts and updates. It would be a nightmare to try to remedy, when I'm messing with other people's codes, that I can't even decipher!
P.S. I kept our connection string inside Application_OnStart, and do the DB connection on the beginning of any ASP pages I need, and DB close at the end of the page(even though I may have forgotten 1 or 2 pages at times, and the system goes in a loop...)
Please let me know if I'm missing any information that I should post to this thread, as I'm not a very savvy poster I'm afraid... please also keep your suggestions flowing! I would love to code the whole damn company website to the same database via PHP, or at least rewrite every damn page, but alas the task, is too daunting to handle by a single developer...
Alan
I still don't understand why you want to do this in VB6/VBScript/ASP. Anything you learn will be out of date. You can call those COM components from within VB.Net/ASP.Net either using InterOp or ASP Compatibility mode.
If you need to use COM then it just adds another layer of complexity to the mix.
Or as others might say, adding a data access layer in to the mix to improve performance, scalability and maintainablity ;-)
You're on the right track urbanzan. Your methodology is spot on, and quite impressive for someone coming from a Perl/PHP background; those languages make it easy to pick up some really bad habits.
If your company is moving to .Net then you're best off implementing your own data access layer in VB.Net Objects and using your 3rd party product's COM controls alongside them. You can use both side by side. Then, if your 3rd party product upgrades to .Net then switching over will be simple.
Or as some would call say, adding a data access layer in to the mix to improve performance, scalability and maintainablity
mrMister, if we were talking .Net business class libraries then I'd agree. Old ASP and COM...that is another story.
Performance gain, probably not as you'll still be using the same ODBC or OLEDB drivers and ADO data objects whether it is in VB or VBScript. If you are using the same connection strings for each connection then conenction pooling will be the same regardless if you use COM or not. Sure the code is pre-compiled instead of parsed but if all you are doing is doing data calls I doubt that the difference will be that noticable.
Scalability, not sure if moving things to seperate layer would help in this case.
Maintainability is debateable. Sure all you similar data access code will be in once spot and easy to maintain. Now each time you want to change it you have to fire up old Visual Studio VB6/C++ and then make the DLL. Then rolling it out is another issue. Have to unregister old, re-register, make sure IIS does not have a hold of it...DLL HELL.
Using old ASP and COM in this way is just not worth it to me. The same concept could be accomplished by moving all of your data access related code to nicely organized include files.
.Net is another subject where creating seperate data and business classes and/or assemblies is a no-brainer.
