| Author |
 Topic  |
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
 Posted - 20 May 2006 : 04:13:43
|
kentk,
quote:
Do you even understand how SQL Server works?
Yes, I am in fact a fully qualified SQL Server administrator so understand perfectly well how SQL works
quote:
Stored procs that are frequently used are complied and then left in the sql cache to be instantly accessed,
As do standard queries, so it is obviously you who have no idea how SQL works |
Edited by - HuwR on 20 May 2006 04:14:13 |
 |
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 20 May 2006 : 05:23:35
|
Woah!
I sense a disturbance in the force.
I don't think he meant it as an insult Huw. It's just that when you're so used to doing things a certain way, it's a little hard to accept differently. You understand.
Anyway, it's not really a big issue at this point.
We don't even have an application let alone any SQL methods to worry about.
I wrote a preliminary CONFIG class to get things rolling.
Add to that a basic Data Access wrapper and you don't have to worry whether the user has Access, MySQL, or MS SQL.
The code can switch from OleDb to Odbc connections on the fly.
It can also batch execute SQL statements with or without parameters.
It's basically a salad of code bits made from Presstopia and DevX
This can be extended by adding DataReader/DataSet return methods.
This set compiles without an IDE.
Just create a structure to work with...
/Root
|- /bin
|- /App_Code
| |-/DAL
| |- config.vb
| |- database.vb
|-compile.bat
Inside complie.bat
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\vbc.exe /nologo /t:library /out:bin\Beta.dll /r:System.dll,System.Web.dll,System.Data.dll App_Code\DAL\*
pause
Basically tells the compiler to create and dump a Beta.dll file into the /bin directory using the code in the App_Code\DAL\ folder.
The path to your vbc.exe can be different depending on what version you have. |
 |
Edited by - Ghostnetworks on 20 May 2006 05:24:46 |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 20 May 2006 : 15:14:07
|
HurW
quote:
Yes, I am in fact a fully qualified SQL Server administrator so understand perfectly well how SQL works
What exactly does that mean? You took some tests and passed?
All I know is what I've worked on:
Fact: stripping all of the inline sql out of an app and placing it into stored procs made life alot happier for my users by taking almost an 1 1/2 hours out of a daily task.
Fact: Another app using all inline sql would basically bring our network to a halt so we could only run it at certain times like early in the morning, after I rewrote it using stored procs it was able to be run at anytime during the day.
There is just 2 examples I can produce, got more if you need it.
I did not mean to insult you in the first post, cause I don't know your background, now I feel I can.
I can also produce multiple arguements for using stored procs just do a search for dynamic sql on www.sqlservercentral.com. There is a whole thread exclusivily written by DBA's stating the benefits of stored procs. There are also many articles about the subject.
GhostNetwork,
I like your plan the n-tier approach, I have no objections to keep supporting Access, I'll look over the stuff you have posted, maybe it is time to take this discussion to emails. I have a co-worker who may help out with coding also. |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 20 May 2006 : 16:26:37
|
just look around there are hundreds of well documented arguments and examples which prove that stored procedures offer little if no benefit over standard queries, even microsofts own tech docs will tell you the same thing
quote:
What exactly does that mean? You took some tests and passed?
Yes, it does, and I have been writing client server database applications for twenty years, using many different flavours of sql and many different programming languages, so if all you are going to do is insult and belittle me I suggest you take your leave of the Snitz community and don't bother coming back |
|
|
|
AnonJr
Moderator
United States
5765 Posts |
Posted - 20 May 2006 : 16:38:44
|
Gee, and I thought when I'd left the Christian Music forum a little while ago I wouldn't be seeing any more religious debates... 
You've got your evidence, he's got his. I don't know enough to say who is more right.
Can we agree to disagree and get on with the .NET? Last post he said he didn't mean to insult...
Even though I probably won't be using it any time soon, I'm trying to glean some .NET knowledge from this discussion. |
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 20 May 2006 : 16:49:45
|
no, in his last post he said quote:
I did not mean to insult you in the first post, cause I don't know your background, now I feel I can.
which says he can now insult me because I have a sql addmin qualification, well I can insult him and tell him to get lost and don't come back, and don't bother using any part of Snitz in your .net endeavours, I can say that because I am one of the copyright holders |
Edited by - HuwR on 20 May 2006 16:50:17 |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 20 May 2006 : 16:51:38
|
kentk,
If anything is eloquent about the quality of someone's reasons is the need to resort to insults. I simply won't have that at Snitz, much less when it is directed to a member of the community such as HuwR, which is one of the developers who put a lot of effort to what the forum code is today, besides being a Snitz copyright holder.
Either you retract from it now, or I will make it my personal pleasure to lock you out of this community. |
Snitz 3.4 Readme | Like the support? Support Snitz too |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 20 May 2006 : 23:23:13
|
Huwr,
Removed Dumb-ass comments made by myself about HuwR
|
Kent
"Wakey, wakey, hands off snakey!" |
Edited by - kentk on 23 May 2006 16:29:40 |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 21 May 2006 : 02:07:01
|
 
Ouch... And I mean that with a capital O.
Well, hopefully this isn't the end of it.
I'm still going to keep the code up; It's a useful wrapper, I think. Even though it may not be used in this project.
And at least someone else can use it in their own apps.
In the middle of all this StoredProc/Inline SQL tiff, I was just wondering...
Kent, I think what you mean is that inline SQL clutters the application.
Well, if there are a lot of consecutive calls to the DB I can see how that can get messy code-side, and slow.
But, Gary mentioned how StoredProcs can be really bad for mod development, and I think he has a point.
If you do solo development, it's easy to get used to StoredProcs because things seem easier to manage. Especially on client-side apps.
There are other ways to get the clean code of StoredProcs without the down side.
I mean If I have a function called "Post(String Subject, String Message, String UserName, Int ForumID, Int TopicID)", it can stay in the DB logic and it will do all the hard work when I call it without cluttering up the rest of the code :
Dim RowsAffected As Integer = Post(strSubject, strMessage, User.Identity.Name, 12, 554)
The Post() function can first execute a statement to get the user id, another to insert the info into the table with the UserID, and one more to update the count stats.
As long as the connection isn't closed between the INSERT and UPDATE statements, your performance won't be affected.
More importantly, you can update/change these statements as needed. It's kinda hard to do that with StoredProcs.
If I'm working on the core app, I don't even have to know what the DB programmer did to post this info into the DB.
Or if I'm writing a mod/customizing my app ( Maybe I decided to add an extra table or two into the mix ), I can reuse or add to the DB logic while keeping my core code clean.
( Very helpful for distributed development )
But with StoredProcs, I'll have to write something completely new that will replace what the original programmer used.
This can really be a delicate situation if there are a number of other functions that rely on the data the StoredProc returns.
Just by moving all the SQL to their own class :
- You still keep your code clean by not dealing with any inline SQL in the core logic.
- Your app will run faster because each Data Wrapper is optimized for each DB and can run consecutive and even nested statements just like in StoredProcs using "IDbTransaction".
This was my primary alternative to StoredProcs. I can't speak for client side apps like you, but it did very well for me on web apps.
- Your app will be easier to fix in case of errors and keep secure, since the DB wrapper, core logic, any new mods, and the HTML can be updated independently.
( Multiple DLLs for each layer or class, even. Simply replace the old DLL with a newer version to update the site. Your users won't even notice! )
- Mod development will be easier, since all anyone making a mod has to do is write a function like "GetPersonalPlanner(UserID)" or something and call it in one of the template files.
( Mod builders even can put out their own DLLs which can make things really simple. Copy > Paste DLL and include the template file where you want it to show. )
So if you're using StoredProcs to streamline the app, there are many, many, many different ways to do so without hard setting your SQL. |
|
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 22 May 2006 : 10:03:22
|
I would like to make a public apology to HuwR. I was very unprofessional on how I handled myself. From now on I will back up my arguements with data and results, not insults.
I would also like to make an apology to the forum as a whole, I conducted myself very unprofessionally, I stepped into the dark side of the force for awhile.
Thank you for giving me a 2nd chance.
Thanks also to my wife, who listened and calmed me down.
At least we can agree to disagree.
|
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 22 May 2006 : 10:07:41
|
So far we have 3 DB's that I know of that will be supported by default:
Access (Office 97?, 2000, XP, 2003)
SQL Server (Versions 7, 2000, 2005)
MySQL (Can someone let me know how far back to go on versions for this one, thanks)
Proposed:
Firebird SQL (sorry never heard of this one) by HuwR
PostgreSQL (haven't heard of this one either) by GhostNetworks
Any others people would like to see supported by default please reply to this topic |
Kent
"Wakey, wakey, hands off snakey!" |
Edited by - kentk on 22 May 2006 15:51:14 |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 22 May 2006 : 11:26:52
|
welcome back kentk, no hard feelings, and yes we will have to agree to disagree
In answer to your db question, by having a data class it should be possible to support any database, so the question should rather be which should be supported by default I think.
As for others I can suggest firebird SQL, I can provide help and a database for this if required, I can also provide asp.net webspace for a test environment for the project if it is needed |
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 22 May 2006 : 13:53:49
|
| Firebird SQL is a free SQL database based on Interbase by Borland |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 22 May 2006 : 16:19:16
|
Thanks HuwR I'll check it out, free stuff is cool!
I would like to start laying this project out visually so bear with me, here's what I've pieced together so far.
We will have:
A presentation layer (The actual pages and web controls, ect)
A business layer with the core logic of the forums
A datawrapper layer for each of the different db's to handle their differences
A dataaccess layer (a common object to send data back and forth to the db's)
The core modules:
Members (Profiles?)
Admin (forum setup)
Corelogic (display of forum)
Others?
Add-On mods - Do we need to specify how add-ons should interface with the core by providing some kind of guidelines? Or leave that to the developers of the add-ons.
Please comment and/or let me know what I missed or don't need.
Thanks
|
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Topic |
|
|
|
Topic Locked
