Hej,

Jag har en bökig fråga som inte går att formulera på något enkelt sätt (och framförallt inte kan beskrivas med en enkel rubrik, därav den dåliga rubriken), så vi får se om någon orkar ta sig igenom denna.

Jag håller på med en produkt där kunderna har ganska unika krav på fält i vissa dialoger. T ex har jag en tabell för projekt, som innehåller fält som är gemensamma för de flesta kunder men skulle jag lägga till varenda fält som en kund önskar så skulle tabellen växa och GUI:t skulle bli alldeles för plottrigt. Alltså har jag implementerat en möjlighet för kunderna att lägga till fria fält på olika ställen i programmet. Kunden talar själv om att dom i t ex projektdialogen vill ha två textboxar, en kryssruta och en combobox t ex, och ger dessa lämpliga captions och fyller comboboxen med data som de själva matar in. För detta ändamål har jag skapat följande databasstruktur (se länk) :

http://82.182.115.177/FreeFields.jpg

Snabb genomgång av tabellerna :
<info>
<b>FreeFieldArea :</b> Innehåller idag 4 st fasta areor men det kan bli fler i framtida versioner. En area motsvarar extrafält till en tabell i databasen och en dialog i GUI:t. En av dessa areor är Projekt som skall kopplas ihop med tabellen Project.

<b>FreeFieldType :</b> Innehåller idag 4 st fasta typer, single line textbox (ID=1), multi line textbox(2), combobox(3) och checkbox(4).

<b>FreeField :</b> Denna tabell fyller kunderna på med de fria fält de vill ha. Här anger de vilken FreeFieldArea fältet tillhör, vilken FreeFieldType det är och även vilken caption och tooltip kontrollen skall ha.

<b>FreeFieldValueList :</b> Denna tabell används endast i samband med ComboBoxar och den innehåller texterna för alla comboitems. Denna hänger alltså ihop med FreeFields där FreeFieldTypeID ha värdet 3 (combobox).

<b>FreeFieldData :</b> Denna tabell håller reda på värdet i ett specifikt fritt fält för en specifik nyckel(key) och area. Fältet Key är alltså primärnyckel i någon av de tabeller som är associerade med en FreeFieldArea. I fallet med comboboxar så är det SelectedIndex som ligger som värde (Data) i tabellen.
</info>
Mitt problem är nu att jag vill skapa en vy av en tabell inklusive dess associerade fria fält. Låt säga att tabellen Projekt för enkelhetens skull bara innehåller ID och namn. Jag vill alltså skapa en SQL-sats som returnerar kolumnerna :

<b>ProjectID, ProjectName, FreeField1Data, FreeField2Data, ...</b>

där alltså alla fria fält för den specifika FreeFieldArea som motsvarar Projekt kommer med som om de vore extra kolumner i tabellen.

Jag vet inte ens hur jag skall börja tyvärr...Går det att lösa enbart med joins? Temporärtabeller? Hur löser man ComboBoxarna, där man måste göra ytterligare en "join" mot FreeFieldValueList för att få det valda textvärdet?

Alla idéer eller synpunkter mottages tacksamt...

Det är oerhört svårt att utgå från en tabell (huvudtabellen) där du vill få data från raderna och sedan joina med dessa dynamiska tabeller där värdena ligger mer kolumnvis. Det är svårt att anpassa så att du får ut datan rad vis till din huvudtabell.

Jag föreslår att du tänker dig alla fält som statiska i en tabell men att du splittar upp det i olika tabeller grupperat på innehållet. Exempel: Du har en stor gigantisk kundtabell med exempelvis information om namn, adress, saldo, etc allt som din kund skulle vilja ha i en enda tabell. Om du då delar upp det på 3 tabeller kundnamn, kundadress, kundekonomi där du i huvudtabellen kundnamn har ett id som är räknare. I tabellen kundadress och kundekonomi lägger du alltid in en rad för kunden åtminstone med id som inte är räknare utan exakt samma som id i huvudtabellen.

Då blir det också lättare att joina tabellerna...

Har jag förklarat det begripligt?

Hej Jenny,

Tack för synpunkterna. Jag tror att jag förstår hur du menar, men det är inte den växande tabellen som oroar mig så mycket som hur man i längden skall lösa det GUI-mässigt. Om varje ny kund kräver ett par nya fält i respektive dialog så blir det snart ohanterligt i gränssnittet. Därför var min plan att i princip inte lägga till fler fasta fält utan låta dem själva "designa" databasen och dialogerna. Visst kan jag fortsätta att lägga till fält i databasen och i GUI:t och låta kunderna dölja/visa enstaka fält, men det känns dels klumpigt eftersom jag redan nu har ca 10 flikar med kontroller i den mest komplexa dialogen. Dels så måste jag hela tiden lyssna på kunderna (vilket inte är fel i sig), men så fort de frågar efter ett fält måste jag släppa en ny version med en uppgraderad databas samt ett nytt GUI. Detta i motsats till en förebyggande lösning som låter kunderna själva lägga till nya fält utan ominstallation m m.

Jag hade hoppats att ovanstående databasdesign skulle lösa problemet med kundernas önskemål för en lång tid framåt, men jag kanske tagit mig vatten över huvudet när det gäller dessa fria fält.

ok, men hur hade du i så fall tänkt att lösa det i gui med dynamiska antal kontroller? Hur vet du var du ska placera ut de nya kontrollerna?

10 flikar med en massa kontroller...vill verkligen alla kunderna ha allting? Är det inte bättre att specialanpassa fönstret för olika slags kunder genom att göra olika slags inställningar. Det är ju lätt att tappa kunder också om fönsterna är alltför komplexa med en massa kontroller hit och dit som gör hela programmet rörigt.

Alla program växer efterhand pågrund av kunders önskemål. De får väl betala för förändringarna? Hinner du inte med förändringarna själv? När en kund ber om förändringar så kan ni väl börja med att diskutera igenom det noga så att ni får med så många förändringar som möjligt på en och samma gång så att inte kunden kommer efter någon vecka eller två för att de kommit på nya saker. När man planerar förändringar i ett ptrogram så är det väldigt viktigt att planera långt fram.

<b>10 flikar med en massa kontroller...vill verkligen alla kunderna ha allting? Är det inte bättre att specialanpassa fönstret för olika slags kunder genom att göra olika slags inställningar. Det är ju lätt att tappa kunder också om fönsterna är alltför komplexa med en massa kontroller hit och dit som gör hela programmet rörigt.</b>

Det är ju därför jag gjort den här funktionen med fria fält för att i fortsättningen inte behöva lägga till fler fält. För att hålla nere komplexiteten...och det går redan idag i programmet att dölja flikar som inte är intressanta för den enskilda kunden. Och nu slipper jag kompilera en ny version varje gång en ny kund dyker upp och har nya önskemål.

Problemet nu är att visa all data i tabellen inklusive fria fält i en gridd och att kunna söka i dessa kolumner.

<b>ProjectID, ProjectName, FreeField1Data, FreeField2Data, ... </b>

Eftersom du har 0 till N FreeFields tänker du nog fel om du ska hämta upp datat på det sättet.
Snarare ska du kanske ha ett resultatset som ser ut så här ungefär:

<code>
FreeFieldName FreeFieldType FreeFieldPosition FreeFieldData
"SpecialPris" "Textbox" "150:500" "145.00"
</code>

Detta kan du loopa igenom för att skapa kontrollerna och stoppa in datat i dem.
Om du vill kombinera med kända fält så kan du t.ex. returnerar flera resultatset från databasen.
Först dina kända fält följt av resultatset som ovan med dynamiska fält.
(Datareader.NextResult)

Hej Ola,

Jag skall binda hela resultatet till en grid och behöver därför "platta till" datan. Det är inga problem i t ex inmatningsbilderna att datan ligger i olika tabeller, detta är redan löst. Problemet är som sagt när jag skall visa alla fält i en lista så att användaren kan sortera, filtrera och gruppera på dessa fria fält (och standardfälten för tabellen). Men det kanske är kört...

Jag tror att ditt problem kan lösas så här. Men det blir lite omständigt.
<code>
SELECT P.Id, FF01.Data, FF02.Data, FF03.Data
FROM Project P
INNER JOIN FreeFieldData FF01
ON P.Id=FF01.PId AND FF01.FieldID = 1
INNER JOIN FreeFieldData FF02
ON P.Id=FF02.PId AND FF02.FieldID = 2
INNER JOIN FreeFieldData FF03
ON P.Id=FF03.PId AND FF03.FieldID = 3
WHERE P.Id = 1007
</code>
Alltså, du ska med JOIN dra upp de logiska tabellerna FF01, 2, 3 eftersom datat finns på olika rader.
Som stored procedures blir det hårdkodat antal dynamiska fält,
men du kan förstås bygga upp en dynamisk SQL-sträng med så många FF-tabeller som du behöver.

Ett annat alternativ är att du i din kod skapar en frikopplad DataTable
och puttar in datat så som du vill ha det. Det är kanske enklare än att lösa det i SQL.

Tack för alla idéer och synpunkter, jag skall ta detta till mig och fundera på hur jag går vidare. Att lägga in de fria fälten i datatable:n i BL (jag antar att det var det du menade med sista stycket) är intressant, men jag måste kolla om detta fungerar prestandamässigt. Det är möjligt att det är acceptabelt om man informerar användarna om att prestandan blir sämre om man visar fria fält i gridden. Då får de ju själva välja, prestanda eller funktionalitet.

Än en gång tack...stänger ärendet nu, men skulle någon komma på med en riktigt bra lösning så är jag givetvis nyfiken.