26. januar 2007 - 11:20Der er
18 kommentarer og 2 løsninger
Access-program til Sql-server
Jeg har et rimelig stort access-system kørende for en kunde, det startede i det helt små, for næsten 10 år siden, med kun knap 100 kunder i systemet og så er det så blevet udviklet i systemet hver år plus at der hele tiden kommer flere data til. Er nok oppe på ca. 10000 oprettede kunder plus alle deres oplysninger, så det er blevet rimeligt tung. Bl.a. derfor ønsker kunden at det skal over på en sql-server, og så til selve spørgsmålet, hvordan gør jeg det bedst, altså med den bedste performance. Jeg har foreslået at jeg laver en ny løsning i .net (altså en internet løsning), men det vil han ikke, da han er ret sikker på at jeg skal bruge mange flere timer på en sådan løsning, og det giver jeg ham jo nok ret i.
Jeg har kigget en del på det efterhånden og så vidt jeg kan se findes der flere løsninger, bl.a. hvor man linker via ODBC til sql, men er ODBC ikke noget skrammel sådan ren performence mæssig. En anden mulighed jeg har fundet er hvor man kobler direkte op til sql-serveren, men her kan jeg åbenbart ikke have noget kode liggende i Access, hver gang jeg prøver at oprette en funktion i 'code-behind', brokker den sig over manglende netwærkforbindelsen (Error accessing file. Network connection may have been lost) og det er noget vrøvl, da jeg fint kan se data'erne fra sql-serveren i formularen.
I would say that the easiest/fastest and therefore the cheapest method is to convert to SQL linked table (ODBC). There is an upsizeing wizard in Access which can do quite a bit for you. Convert table and I think also queries.
Another method is to convert to Access ADP (data projects) where the Access database is directly connected to a database in SQL Server. This is going to take quiet a bit longer I would think and if you havent worked with ADP's then it can be a bit of a problem.
You wrote: "En anden mulighed jeg har fundet er hvor man kobler direkte op til sql-serveren, men her kan jeg åbenbart ikke have noget kode liggende i Access" I dont know of any limitations with code when working with Access/SQL Server.
When you use ODBC you can also make "Pass-Through" queries. The SQL in th equery is sent to the server and executyed there instead of in Access. THis can give a much better performance than in plain Access. You also have the possiblity of backing up your dB etc.
ODBC fungerer fint. Jeg har lavet statistiksystem med over 2 mio records på en SQL-server. Det der tager tid er hvis du loader f.eks. 100.000 records via ODBC - men det gør du jo ikke.
Jeg har desuden et flerbrugersystem kørende, hvor der er 3 primære brugere og nogle der kigger en gang imellem. Der ligger ca. 70.000 records. Det fungerer perfekt med meget hurtige svartider. Jeg kan ikke mærke forskel på om der er 1000 records i Access eller de 70.000 på SQL-serveren.
Jeg bruger SQL-server 2000 med Access 2000 som brugerflade.
terry>> Jeg tror at du har ret i at det vil tage lang tid at konvertere til ADP, for når jeg kører guiden og det tool til at analyserer med, er der flere hundrede steder jeg skal rette. Så kan jeg næsten ligeså godt starte forfra.
oz1aiv>> Pga. af ovenstående, og pga. dine erfaringer, ser det ud til at det er den vej jeg skal gå.
Så nu har jeg konverteret det til ODBC ved hjælp af access guiden, og det ser straks mere overskuelig ud, jeg har dog det problem at jeg ikke kan opdatere sql-databasen, den er åbenbart skrivebeskyttet, også selv om jeg åbner tabellen direkte via sammenkædningen i Access. Det er sikkert en lille ting, men det kan i nok svare hurtigere på end jeg kan finde det på nettet?
der er noget jeg er i tvivl om, når man kobler op via ODBC, hvordan gør man det så rigtigst. Jeg har som sagt lavet konverteringen via Access guiden, og her kan jeg under 'Styring af sammenkædede tabeller' se at linket til databasen er DATABASE=MinTestdatabase, hvor er den forbindelse gemt henne.
De andre test jeg har lavet, har jeg selv lavet linket via 'Sammenkæd tabeller', valgt ODBC og oprettet en DNS datakilde, og når jeg gør det virker det med opdatering fint. Under 'Styring af sammenkædede tabeller', står der nu at forbindelsen er 'DNS=TestDNS;DATABASE=MinTestdatabase'.
Hvad er forskellen, jeg ved godt hvad en DNS forbindelse er, men hvad med den første forbindelse, er det en direkte opkobling til sql-server uden DNS?, er det i det hele taget en ODBC-forbindelse, hvor gemmes oplysningen henne, for hvis det er en direkte opkobling, så kan det jo have noget at gøre med rettighedder, altså at der mangler skriverettighed til den bruger der kobler op.
Jeg tror ikke at det betyder noget, hvordan du etablerer din ODBC. Jeg har brugt både Bruger-DSN, System-DSN og Fil-DSN - så vidt jeg ved gør det ingen forskel på rettighederne på SQL-serveren. Jeg har ikke her hjemmefra mulighed for at se, hvordan min 'Styring af sammenkædede tabeller' ser ud.
Jeg går du fra, at du logger på med SQL-serverens administrator.
Har du prøvet ovenstående 'Create table.....' direkte på SQL-serveren? (Jeg kan ikke huske, om kommaet efter 'nonclustered' skal med, men det finder du jo nok ud af).
Ja jeg har prøvet at køre den create table..., men jeg ved ikke hvordan jeg laver sammenkædningen DATABASE=MinTestdatabase, den eneste mulighed jeg kan se, er via DNS
Forøvrig, ligner den tabel jeg opretter via dit script fuldstændig de andre tabeller, som jeg alså ikke kan opdatere, altså hvad angår constraint, primary key og identity, så jeg tror ikke det er det der er galt.
Jeg ved ikke om jeg logger på med SQL-serverens administrator, da jeg ikke kan finde hvor forbindelsen DATABASE=MinTestdatabase er gemt henne.
Mystisk. Jeg havde præcis samme problem første gang jeg skulle opdatere en tabel på SQL-serveren med Access. Det problem løste jeg som beskrevet med create table... Jeg har brugt denne metode på både SQL-server 6.5 og SQL-server 2000 uden problemer.
Jeg laver normalt ODBC opsætningen i ACCESS med fanebladet 'Maskindatakilde' (det må svare til SYSTEM-DSN).
Jeg kan nok ikke hjælpe dig videre - men jeg skal nok vende tilbage, hvis jeg kommer i tanke om noget.
sorry for my absence, I've been away for the weekend. Th eproblme you rhaveing is almost certainly a security issue. When you make a DSN you can choose which method that SQL server is to use to authorize login's. If you choose "With Windows NT authentication" the you will need to add a user in SQL SErver and give the user the correct permissions. Or you can make the tables/queries public and then choose which permissions public is to have.
lige for at præcisere hvad mit spørgsmål går ud på nu. Fakta: 1. Hvis jeg opretter forbindelsen fra Access med fanebladet 'Maskindatakilde, som du (oz1aiv) åbenbart også gør, så virker det fint. (forbindelsen står som 'DNS=TestDNS;DATABASE=MinTestdatabase') 2. Hvis jeg kører opgraderings-guiden i Access, virker det ikke, så kan jeg ikke opdatere noget. (forbindelsen står som DATABASE=MinTestdatabase)
Så mit spørgsmål nu er egentlig, hvad er forskellen på de 2 forbindelser, og hvor bliver forbindelsen i punkt 2 gemt henne, jeg ved ikke hvilke rettigheder forbindelse 2 har, når jeg ikke kan finde den?????
Jeg kan selvfølgelig også bare bruge metoden under punkt 1, men hvis nu den anden metode er mere effektiv (og det er den måske, siden Microsoft vælger at bruge den)
I must admit, it is yeasr since I used ODBC linked tables, prefer using ADP's. I have ALWAYS used a DSN, this make things much more flexible. You can for example have one DSN for your ets environmnet and another for production and just relink when you want to change, selecting the appropriate DSN. Also, as far as I can see, if you choose to use a trusted connection (if it works as it should) then all users have the same permissions. If you use a DSN then you can decide what permissions each user has.
I dont understand why you cant update when you use the upsizing wizard. I would have assumed that you have th ecorrect permissions if you can create the database in the first place.
Nu fandt jeg, ved megen søgning, løsningen på mit sidste spørgsmål, hvad forskellen er på de 2 forbindelser. De er begge 2 en DNS forbindelse, forskellen er at forbindelse 1 er en maskine-dns og 2 er en file-dns, jeg fandt bl.a. flg. interessante ting om file-dns "I prefer using the file type DSN for Access applications. With this type of DSN, the connection string becomes part of the table definition so you don't have to set the data source up on the customer's computers." (ikke fordi jeg vil bruge denne løsning, da min kunde ikke skal koble op på min database, men jeg synes det er en interessant oplysning)
I kan læse det hele her http://www.sqlservercentral.com/columnists/kKellenberger/accesstosqlserverlinkingtables.asp Der er 2 artikler, en som beskriver 'The upsizing wizard' og en der beskriver 'Linking tables' og de er efter min mening ret gode. Jeg ved ikke om dine link er gode terry, da jeg ikke har læst dem (og det gør jeg nok heller ikke, for nu tror jeg at jeg har det jeg skal bruge), men måske jeg vender tilbage til dem senere hvis (når) jeg støder ind i problemer.
Jeg har ikke fundet ud af hvorfor Access guiden ikke giver mig skriverettighed, men det er også ligemeget nu, det virker fint når jeg selv opretter en DNS uanset om det er en file- eller maskine-DNS
Så i skal have tak for hjælpen, jeg synes i skal dele pointene, da i begge er kommet med svaret (ODBC/DNS).
Thanks drop a comment if you need further help here
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
