---

--
If 0 thinks it looks like O, then 0 got a problem right?

---

Kim Noer wrote:
>
>

Kan du uddybe det spørgsmål lidt?

mvh

Jesper Brunholm

---

Som svar på skriblerier forfattet af Jesper Brunholm

> Kim Noer wrote:
>
> Kan du uddybe det spørgsmål lidt?
>
Hvorfor

ODBC driveren til C5 fås hos leverandøren og resten foregår i
dk.edb.internet.webdesign.serverside.asp

Btw principielt er der ikke nogen forskel på den generelle brug af ADO hvis
man bruger anden ODBC database - fx MySQL, MSSQL, Access whatever

mvh/Peter Lykkegaard

---

Alt afhængig af hvad du vil, vil jeg anbefale at du overvejer at bruge
en anden mulighed end ODBC. F.eks. at overføre data ud og ind af C5
via tekst/komma filer.

Jeg har i mit firma lavet en hjemmeside med mulighed for ordre, login
og produktvisning.

Alle data som overfører mellem hjemmeside og C5 sker via tekst filer
som sende og hentes med FTP. Alt sker i C5 og det kører 100%
automatisk uden at nogen skal aktivere noget som helst. Det kræver kun
en aktiv computer med et schedule program installeret.

Jeg har snakket med andre som har prøvet at bruge ODBC og det er ikke
de bedste erfaringer de har. De problemer jeg har hørt om er at det er
ustabilt og læsning/skrivning er langsomt, og så er prisen også et
minums, jeg mener det er noget med 20 K for skrive og 5 K for læse.

--
....::Hilsen Erik

---

Som svar på skriblerier nedfældet af Erik Hansen :

> Jeg har snakket med andre som har prøvet at bruge ODBC og det er ikke
> de bedste erfaringer de har. De problemer jeg har hørt om er at det er
> ustabilt og læsning/skrivning er langsomt,

Efter min mening fungerer det ganske fortrinligt sammen med fx Excel
Kan dog drille lidt
Muligvis driller det mere sammen med ASP, da jeg har en formodning om at
driverne ikke skrevet til den slags "mishandling"

> ... og så er prisen også et
> minums, jeg mener det er noget med 20 K for skrive og 5 K for læse.

Jeps, det er ikke gratis

Skrive rettigheder skal man være lidt varsom med, da man svjv skriver
direkte i tabellerne uden det alm C5 forretningslogik imellem
En bogførers værste mareridt kunne man næsten sige
En mulighed er at bruge kladder der så skal godkendes manuelt og bogførings
for at alle tabeller bliver korrekt opdateret og sporingen er i orden

mvh/Peter Lykkegaard

---

> Jeg har snakket med andre som har prøvet at bruge ODBC og det er ikke
> de bedste erfaringer de har. De problemer jeg har hørt om er at det er
> ustabilt og læsning/skrivning er langsomt, og så er prisen også et
> minums, jeg mener det er noget med 20 K for skrive og 5 K for læse.

http://www.apply-it.com/dk/erp/xal/index_xal.htm > Priser
Nu er det godt nok til XAL, men mener bestemt, at priserne er nogenlunde de
samme.
Altså 3000 kr. for RO og 8000 kr. for RW.

--
Mvh. Jesper

---

On Wed, 09 Oct 2002 22:01:49 +0200, Erik Hansen <00@mail.dk> wrote:


>Jeg har snakket med andre som har prøvet at bruge ODBC og det er ikke
>de bedste erfaringer de har. De problemer jeg har hørt om er at det er
>ustabilt og læsning/skrivning er langsomt,

Korrekt!

> og så er prisen også et
>minums, jeg mener det er noget med 20 K for skrive og 5 K for læse.

Inden der går for meget ammestue i den: 4.800 for R/W.

mvh /Snedker
---
Klip det citerede væk, du ikke besvarer
Besvar venligst under det citerede

---

Som svar på skriblerier nedfældet af Snedker :

> On Wed, 09 Oct 2002 22:01:49 +0200, Erik Hansen <00@mail.dk> wrote:
>
>> Jeg har snakket med andre som har prøvet at bruge ODBC og det er ikke
>> de bedste erfaringer de har. De problemer jeg har hørt om er at det
>> er ustabilt og læsning/skrivning er langsomt,
>
> Korrekt!
>
Hvordan ustabilt?
Det har jeg ikke oplevet i forb med Office apps
Det har dog ikke været brugt hver dag, men kun i forb med nogle
månedsrapporter
Her har det da virket ganske fornuftigt (kun read)

mvh/Peter Lykkegaard

---

On Fri, 11 Oct 2002 12:34:06 +0200, "Peter Lykkegaard"
<polonline@hot.mail.com> wrote:


>Hvordan ustabilt?

Læsemodulet virker fint, men skrivemodulet er ustabilt. Selv tidligere
medarbejdere hos Damgaard betvivler at ODBC-standarden bliver
overholdt.

Mit eget problem har ligget i opdatering af recordsets
(bilagstabellen), hvor jeg skulle opskrive værdien af
følgeseddelsnummeret. Det var et batch-job der kørte. Nøjagtig ved
hver 7. rs.update fejlede den: posten låst af en anden bruger (hvad
den definitivt ikke var).

Problemer med at ikke at kunne gemme poster overhovedet (det være sig
fra Access/Excel/VB). Forekomst af denne fejl var sporadisk. Det blev
benyttet drivere af nyeste dato til Navision C5 Light. (R/W).

Kundens Concorde-forhandler kunne ikke hjælpe. Damgaard Data kunne
heller ikke. Og det var så det.

Løsningen blev at skrive til en dat-fil i stedet, bede et eksternt
firma om at lave en kørsel, som foretog de nødvendige opdateringer i
Concorden.

DERFOR anbefaler jeg til enhver tid WinFinans. Det er så dejligt åbent
og fleksibelt. Det kan man næppe beskylde Damgaard-produkter for.

mvh /Snedker
---
Klip det citerede væk, du ikke besvarer
Besvar venligst under det citerede

---

Som svar på skriblerier forfattet af Snedker

> On Fri, 11 Oct 2002 12:34:06 +0200, "Peter Lykkegaard"
> <polonline@hot.mail.com> wrote:
>
>> Hvordan ustabilt?
>
> Læsemodulet virker fint, men skrivemodulet er ustabilt. Selv tidligere
> medarbejdere hos Damgaard betvivler at ODBC-standarden bliver
> overholdt.
>
Ok, dér er mine erfaringer lidt begrænset
C5's database ligger noget langt fra en relationel database (den er
hierarkisk)
Jeg vil tro at det er pga dette der er problemer

> DERFOR anbefaler jeg til enhver tid WinFinans. Det er så dejligt åbent
> og fleksibelt. Det kan man næppe beskylde Damgaard-produkter for.
>
Jeg har arbejdet med XAL for nogen år siden, det er nu særdeles flexibelt at
arbejde med
Vel at mærke hvis man holder sig i XAL
Åbenhed overfor andre programmer/3die part er ikke så velgennemført, for at
sige det pænt
Eller var på det tidspunkt - kan være der kommer andre boller på suppen nu


mvh/Peter Lykkegaard

---

On Fri, 11 Oct 2002 14:45:05 +0200, Snedker
<morten@nospam_dbconsult.dk> wrote:

>DERFOR anbefaler jeg til enhver tid WinFinans. Det er så dejligt åbent
>og fleksibelt. Det kan man næppe beskylde Damgaard-produkter for.

Valget af system bør afgøres af hvordan systemet understøtter
forretningslogikken - ikke om systemet er åbent!


--
Thomas

---

On Fri, 11 Oct 2002 12:18:35 +0200, Snedker
<morten@nospam_dbconsult.dk> wrote:

>>minums, jeg mener det er noget med 20 K for skrive og 5 K for læse.
>
>Inden der går for meget ammestue i den: 4.800 for R/W.

Jeg snakkede med vores forhandler i dag, og fik at vide at prisen for
læse via ODBC er 1.500.- så det er jo ikke så slemt som jeg troede.

--
....::Hilsen Erik

---

On Fri, 11 Oct 2002 15:35:12 +0200, Erik Hansen <00@mail.dk> wrote:

>On Fri, 11 Oct 2002 12:18:35 +0200, Snedker
><morten@nospam_dbconsult.dk> wrote:
>
>>>minums, jeg mener det er noget med 20 K for skrive og 5 K for læse.
>>
>>Inden der går for meget ammestue i den: 4.800 for R/W.
>
>Jeg snakkede med vores forhandler i dag, og fik at vide at prisen for
>læse via ODBC er 1.500.- så det er jo ikke så slemt som jeg troede.

Næh - stadig synes jeg deres licensering sux! En af mine kunder er en
produktionsvirksomhed. Hver gang de afslutter en ordre (afslutter
produktion af varenummer), så skal der genereres en følgeseddel. Dette
følgeseddelsnummer skal komme fra C5.

Se, nu har de en stor maskinhal, så for at medarbejderne ikke skal
bevæge sig så langt, så står der 3 maskiner i produktionen, hvor de
kan stemple ind og ud på ordre. Men da Concorde opererer med samtidige
brugere, ja så skal der altså bruges 3 licenser (selvom det måske er
usandsynligt at der bliver skrevet til Concorde fra to forskellige
maskiner i samme split-sekund - men er det noget man som udvikler kan
tillade sig at løbe an på?). Og hver licens koster altså kr. 3.800.
Det er simpelthen for latterligt...synes jeg.

Jeg er vist ved at være vel off-topic. Men jeg fik da luft.

mvh /Snedker
---
Klip det citerede væk, du ikke besvarer
Besvar venligst under det citerede

---

Som svar på skriblerier forfattet af Snedker

> Næh - stadig synes jeg deres licensering sux!

>... Men da Concorde opererer med samtidige
> brugere, ja så skal der altså bruges 3 licenser (selvom det måske er
> usandsynligt at der bliver skrevet til Concorde fra to forskellige
> maskiner i samme split-sekund - men er det noget man som udvikler kan
> tillade sig at løbe an på?). Og hver licens koster altså kr. 3.800.
> Det er simpelthen for latterligt...synes jeg.

Er det?
Det er da nøjagtig den samme politik som Sun, TekLynx, SuperOffice, SAP,
Baan, og nu M$ samt mange andre kører efter

> Jeg er vist ved at være vel off-topic. Men jeg fik da luft.
>
Hmm, ved ikke lige hvor en debat om licenser kan føres henne
Vi kan prøve dk.edb?

Followup-To: dk.edb
Evt svar på dette indlæg havner i dk.edb, med mindre man selv retter lidt i
headeren

mvh/Peter Lykkegaard

---

"Erik Hansen" <00@mail.dk> wrote in message
news:mpkdqu42iqv1tvbj1igm5s4vnvm19jk6gp@4ax.com...

> Jeg snakkede med vores forhandler i dag, og fik at vide at prisen for
> læse via ODBC er 1.500.- så det er jo ikke så slemt som jeg troede.

Det er måske ikke dyrt, hvis man kan bruge denne adgang til nogen
fornuftigt!

Jeg er igang med at lave et website der kører PHP, men jeg har været nødtil
af kopiere data over i en MSSQL med noget data formatering imellem. Dette er
nødvendigt for at kunne trække dataene ud, uden alt formange selects. JOIN
virker f.eks dårligt, da to fletter som skulle være relatere til hinanden
ikke indeholder samme data!

Allan

---

"Erik Hansen" <00@mail.dk> wrote in message
news:mpkdqu42iqv1tvbj1igm5s4vnvm19jk6gp@4ax.com...

> Jeg snakkede med vores forhandler i dag, og fik at vide at prisen for
> læse via ODBC er 1.500.- så det er jo ikke så slemt som jeg troede.

Det er måske ikke dyrt, hvis man kan bruge denne adgang til nogen
fornuftigt!

Jeg er igang med at lave et website der kører PHP, men jeg har været nødtil
af kopiere data over i en MSSQL med noget data formatering imellem. Dette er
nødvendigt for at kunne trække dataene ud, uden alt formange selects. JOIN
virker f.eks dårligt, da to fletter som skulle være relatere til hinanden
ikke indeholder samme data!

Allan

---

Som svar på skriblerier forfattet af Allan Kok

> JOIN virker f.eks dårligt, da to fletter som skulle
> være relatere til hinanden ikke indeholder samme data!

Hvilke tabeller er der tale om
Sandsynligvis er tabellerne kun relateret via andre tabeller

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:ao8tna$leh$1@sunsite.dk...
> Som svar på skriblerier forfattet af Allan Kok
>
> Hvilke tabeller er der tale om
> Sandsynligvis er tabellerne kun relateret via andre tabeller
>

Det var tabler som vi selv havde oprettet i C5, med relationer til nogen af
de oprindelige!

(Det var en C5 programmør der stod for det arbejde)

Allan

---

Jakob Møbjerg Nielsen skrev:

> Fra Snedkers header:
>
> Content-Type: text/plain; charset=utf-8

Og Snedkers indlæg er også i utf-8 - så det er sådan set fint nok.
UTF-8 er et fuldt ud gyldigt tegnsæt på usenet - problemet er bare
at det ikke er understøttet af alle klientprogrammer.

> Det bør være:
>
> Content-Type: text/plain; charset=ISO-8859-1

Det er rigtigt i den forstand at der ikke er grund til at poste i
et mere avanceret tegnsæt end højst nødvendigt. Det vil sige at
hvis et indlæg kun indeholder ascii-tegn sender man i us-ascii,
normale danske indlæg kan (og bør) holdes i iso-8859-1, har man
brug for ¤-tegnet (euro) kan man bruge iso-8859-15 og er det ikke
nok kan man så benytte utf-8.

Jeg vil benytte lejligheden til endnu engang at reklamere for
brugen af programmet morVer. Det er på grund af det program at jeg
kan læse og svare på utf-8-indlæg uden problemer - og fx sende
dette indlæg som iso-8859-15 (på grund af eurotegnet). Samtidig
klarer det en række andre skavanker ved egne og andres usenetindlæg
(bl.a. klipper morver bundcitater væk - dét er en særdeles brugbar
egenskab.

FUT: dk.edb.internet.software.mail+news (svar på dette indlæg
havner i nævnte gruppe og kan ikke ses her)
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.

---

morten@nospam_dbconsult.dk skriver:
>Jeg er vist ved at være vel off-topic. Men jeg fik da luft.

Det går nok -:)

Har du gjort noget for nylig? Når jeg læser DINE mails hér i gruppen, så
er de danske karakterer helt "out of order"!
--
Venlig hilsen
Torben Borre Larsen
[torben@dui.dk] [www.dui.dk]

---

Kim Noer wrote:

Kan I så lige lade være, der er faktisk blevet sendt en cancel afsted til
mit indlæg (ca. 1-2 min. efter det blev postet).

Anyway, det lykkedes rent faktisk at læse direkte via ODBC og ud på en asp
side. I øvrigt er den langsom - men den er ikke umiddelbart langsommere end
normal 'tekst-import'. Ved skrivning er det index der sætter hastigheden
(ganske alvorligt, med 3-5 index, og 60000 records snakker vi om 5-6 år
(sådan er det hver dag!)).

--
I doubt, therefore I might be.