option explicit / DIM av variabler

Äh, det är bara folk utan vilja som tycker saker är jobbiga. Jag har rökt sporadiskt i femton år men den senaste tiden har jag lagt av helt. Det var inte roligt längre.

Allt går om man bara vill!

---
Från tråden ovan:
INFO: Object Hungarian Notation Naming Conventions for VB (Q173738)

Forumet är min lag, jag testar det alternativa tillvägagångssättet redan nu.

While we're at it...

När vi nu snackar Politiskt Korrekt Kod, vad döper ni tabeller vars främsta syfte är att agera pekare åt andra tabeller?

Med risk för att bli avstängde från forumet vågar jag inte visa mina mest relevanta exempel. Dock har jag ett exempel som känns rätt okej:

[access]
x_ID
x_userID
x_menuID

(Finns användarens ID och länkens ID har användaren behörighet till den specifika länken.)

För er som inte fattar kan jag förtydliga i så fall:

[access]
intID
intUserID
intMenuID

Förslag på namnval?? Egenligen var det ett jättedumt exempel eftersom det är så uppenbart, föreställ er något som inte är uppenbart...

Du skall ju med namnet ge "läsaren" en uppfattning om vad tabellen gör, och det du bygger är ett slags filter för access till menyer, eller?

Jag skulle då kalla tabellen för [projekt_menuaccessfilters] där projektet är projektet tabellen tillhör.

Varför jag lägger till projektet är för att du kan ha liknande tabeller i andra databaser, och det finns då möjlighet att du glömmer bort vilken databas som är öppen och du gör då en ändring som kan skada databasen, anger du dock projektet så är du säker på att du gör rätt. ;)

I frågan om variabler så skall ju namnet säga dels vilken datatyp variabeln har och den skall beskriva vad som finns i den.

Så en variabel som innehåller namnet på en inloggad person borde se ut såhär: strLoginName

Mvh, Vide

Grejt! You've got a point! :-)

Men det där med projekt vet jag inte... inte just nu i alla fall. En klar fördel med det tillvägagångssättet jag arbetat fram är just att den är projektfri, alltså koden i sig är inte knutet till mig, projekt, kund, Olai Lindgren eller någon annan faktor...

Det var rätt skönt när en kund nyligen bytte namn! Det skulle varit rätt stökigt om gamla tabeller hetat namn med det gamla namnet och nya tabeller namn med det nya namnet!

"Gött, gött, gött" gick jag runt och sa en hel eftermiddag.

Så du får verkligen kämpa för att få mig att lägga in projektnamn / kundnamn i namnet på tabeller! Men never say never, jag är öppen för förslag!

---
Plural vs. singular??

Du skriver [projekt_menuaccessfilters], alltså i plural. Själv har jag fokuserat på korta tabellnamn men om man tänker lite finns det egentligen inte sågon större poäng i det. Främst för man skriver tabellnamnen så sälla att man lika gärna kan skriva några tecken extra.

Jag är kluven i frågan. Jag skriver [users], [news] och [links] men inkonsekvensen är total då jag också skriver [job], [menu] och [activeJob].

(I och för sig är det olika sammanhang men endå... det känns inkonsekvent och slumpvis...)

Plural vs. singular??

Enkelt, en tabell (med bra databasstruktur) innehåller 99% av fallen multipla poster och bör således vara plural. Jag kan faktiskt inte se framför mig en databasdesign som är så statisk att den bara innehåller en post.

Men det där med projekt vet jag inte...

Självklart skall du inte sätta ett sådant prefix om du inte har någon anledning till det, vilket, som du beskriver, du inte har för tillfället. ;)

Personligen skapar jag alltid projekt för mina arbeten/hobbyprojekt, och ofta har jag liknande funktioner (och således tabeller) för de olika projekten, t.ex inloggning, användartabell, forum o.s.v.

Mvh, Vide

Personligen skapar jag alltid projekt för mina arbeten/hobbyprojekt, och ofta har jag liknande funktioner (och således tabeller) för de olika projekten, t.ex inloggning, användartabell, forum o.s.v.

Ja... jo... vi lever i samma värld... Nästan. Jag har inte bara liknande, utan *exakt samma* funktioner. Jag kan då ta ett befintligt projekt, kopiera det och klistra in kåden i det nya projektet... färdigt med dokumentation och allt.

Sen får man givetvis lägga ner energi på kundspecifika önskemål men det är mest roligt. Allt det jobbiga är ju redan avklarat!

<%
SQL = "SELECT * FROM [users] WHERE [x_ID] = " & request("ID") & ";"
set mySQL = Conn.Execute(SQL)
on error resume next

x_firstname = mySQL("x_firstname")
x_lastname = mySQL("x_lastname")
x_company = mySQL("x_company")
x_email = mySQL("x_email")
x_street = mySQL("x_street")
x_zip = mySQL("x_zip")
x_city = mySQL("x_city")
x_phone = mySQL("x_phone")
x_directphone = mySQL("x_directphone")
x_cellular = mySQL("x_cellular")
x_fax = mySQL("x_fax")
x_created = mySQL("x_created")
x_lastVisit = mySQL("x_lastVisit")

%>

i det här fallet skulle jag nog gjort såhär...

SQL = "SELECT * FROM [users] WHERE [x_ID] = " & request("ID") & ";"
set mySQL = Conn.Execute(SQL)
on error resume next
dim dic 'dictionary
dim f 'field
set dic = Server.CreateObject("Scripting.Dictionary")

for each f in mySQL.Fields
dic(f.Name) = f.Value
next

Sen har man ett dictionary med alla sina variabler i, färdigt att användas på sidan.

Fördelen är att man kan även loopa in Request.form i det om man postar till samma sida

Sen kan man använda dictionaryt till att loopa in alla variablerna i ett recordset och spara.

Poängen är att man kan lägga till ett fält i databasen, ochslänga in det som textfält på sidan och det funkar direkt.

Annars brukar jag dimma saker där jag behöver den, brukar försöka gruppera kod som hör ihop i grupper på sidan.

Dictionary känner jag inte till. Men på det sättet du skriver så framstår det som en teknik att ta till sig. Vad jag förstår av trådarna på forumet är det inte så många som använder dictionary men det kan bero på att de flesta inte känner till det(??)

Vad är det för skillnad / likhet mellan dictionary och getRows?

Ett dictionary-objekt har ingenting med databasen att göra, utan är ett kollektion-objekt precis form eller querystring, skillnaden ligger i att du kan förändra värdet av ett kollektionselement, vilket du ju inte kan göra i en request.form.

Läs mer här