Re: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-25 Thread Alex Wulms
] >No, wrong. ] >Look at the dreaded date field. Almost every vendor as a different way of ] >specifying how to insert date into it's DB system. this means that ] >import/export script generating is DB dependend. Besides talking about dates, Every ]DB vendor that follows the ANSI standard allo

Re: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-25 Thread Alex Wulms
] I would like the format to be verry MSX aware. I would like to use it ] (unchanged) on a real MSX. SQL on MSX isn't done yet. ] So therefore i prefere that the baseformat is flat text, MS(X) -dos style (so ] ended.) As far as I'm concerned, the server can contain a database with an html fron

Re: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-25 Thread Ricardo Jurczyk Pinheiro
Em qui, 25 jan 2001, Daniel Caetano escreveu: > >Look at the dreaded date field. Almost every vendor as a different way of > >specifying how to insert date into it's DB system. this means that > >import/export script generating is DB dependend. Besides talking about dates, > >if an american w

Re: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-25 Thread Daniel Jorge Caetano
>No, wrong. >Look at the dreaded date field. Almost every vendor as a different way of >specifying how to insert date into it's DB system. this means that >import/export script generating is DB dependend. Besides talking about dates, >if an american writes 2/1/2001 he means the first of februarie

Re: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-25 Thread Daniel Jorge Caetano
>No, wrong. >Look at the dreaded date field. Almost every vendor as a different way of >specifying how to insert date into it's DB system. this means that >import/export script generating is DB dependend. Besides talking about dates, >if an american writes 2/1/2001 he means the first of februarie

Re: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-25 Thread David Heremans
My 2-cents again. I'll set my comments on your remark in between the lines :-) On Wednesday 24 January 2001 16:02, you wrote: > ok, ok. I'll give my 2 cents as well :-) > > - The data is 'protected', for example it's simply not possible to have > double entries (based on several fields) Primary k

RE: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-24 Thread Arno Bakker
them around. But it shouldn't be the argument not to use a database for structured data. grtz, Arno -Original Message- From: David Heremans [mailto:[EMAIL PROTECTED]] Sent: woensdag 24 januari 2001 15:40 To: [EMAIL PROTECTED] Subject: Re: .msx server, SCC/DAC/SRAM (to database or n

Re: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-24 Thread David Heremans
On Wednesday 24 January 2001 15:29, you wrote: > some people figured out in the seventies (or was it the sixties) that > structured data can be handled more easily in a database. People still > agree on that idea. > > So lets have it... why not use a database?? > > Arno Call it a flat-file databa

RE: .msx server, SCC/DAC/SRAM (to database or not to ..)

2001-01-24 Thread Arno Bakker
PROTECTED]] Sent: woensdag 24 januari 2001 16:04 To: [EMAIL PROTECTED] Subject: .msx server, SCC/DAC/SRAM Maarten ter Huurne wrote: > Packager ID: Server: > [EMAIL PROTECTED] - > msxpackbeta beta.msxpack.org > msxpack msxpack.mirror.

.msx server, SCC/DAC/SRAM

2001-01-24 Thread Ricardo Bittencourt Vidigal Leitao
Maarten ter Huurne wrote: > Packager ID: Server: > [EMAIL PROTECTED] - > msxpackbeta beta.msxpack.org > msxpack msxpack.mirror.nl > msxpack release.msxpack.org > mr_x msx.whatever.com:8080 Just to improve the idea: .msx database servers do