ASP/Access omzetten naar php/(MySQL)

[JJzD]

Hoi,

Momenteel hebben wij een database draaien op ASP/Access. Nu gaan we de webpagina omgooien. Ik zou graag een aantal dingen aanpassen, maar ken geen ASP.
Dus nu zou ik graag zien dat de Access datbase om kan worden gezet naar een MySQL. Ik heb daar al de conversietool van MySQL zelf van gebruikt, maar die geeft SQL errors.
Wat ook mogelijk zou zijn is de Access db blijven gebruiken. Maar om die met php te gebruiken moet hij verbonden worden via ODBC. En dat kan via een DSN, maar niet DSN-less. En aangezien het bij een hostikng bedrijf staat en om verschillende databases gaat kan ik moeilijk vragen of ze ff een dsn aanmaken.

Ik loop dus spaak op:
- Geen dsn-less verbinding php/Access
- Geen mogelijkheid gevonden om Access naar MySQL om te zetten.

Weet iemand hier iets op?
Of is het makkelijker om mezelf gewoon ASP te leren )Niet zo heel verschillend van PHP d8 ik?)

Kun je niet gewoon exporteren naar een csv bestand of naar een standaard SQL bestand?
Want het gaat eenvoudig uiteindelijk om het verkrijgen van INSERT queries.

********** schreef op 24-10-2005 @ 16:06 :
Kun je niet gewoon exporteren naar een csv bestand of naar een standaard SQL bestand?
Want het gaat eenvoudig uiteindelijk om het verkrijgen van INSERT queries.

Als je de CSV hebt is het niet moeilijk meer opzich om er insert queries van te maken. Simpele search and replace en je bent er.

Ninh schreef op 24-10-2005 @ 16:21 :
Als je de CSV hebt is het niet moeilijk meer opzich om er insert queries van te maken. Simpele search and replace en je bent er.

Als je een CSV file hebt hoef je geen insert queries meer te hebben

PHP is een programmeertaal en ASP niet. ASP is alleen de MS standaardmanier om serverside scripts uit te voeren. Binnen ASP kan je dan ook diverse talen gebruiken als je dat zou willen. Waaronder JScript, JavaScript en VBScript.
Javascript heeft in de verte iets weg van PHP, maar VBScript niet echt.

Probeer het te porten naar PHP of ASP-X in C#.NET ofzo. Dan kan je met je xs database gewoon dsnless blijven werken

********** schreef op 24-10-2005 @ 16:29 :
Als je een CSV file hebt hoef je geen insert queries meer te hebben

Hangt geheel af van je database schema.

Ninh schreef op 24-10-2005 @ 17:04 :
Hangt geheel af van je database schema.

En welk deel zou volgens jou dan niet mogelijk zijn binnen een MySQL database?

********** schreef op 24-10-2005 @ 17:19 :
En welk deel zou volgens jou dan niet mogelijk zijn binnen een MySQL database?

Een CSV is ge-exporteerd op volgorde van kolommen zoals die in de de originele access db zaten. Je zou in je mysql database dan exact dezelfde kolomvolgorde aan moeten houden. Dat kan wenselijk zijn, maar ook niet. Bovendien kunnen datatypen niet overeenkomen, maar volgens mij neemt mysql dit sowiesow niet zo nauw hiermee.

Ninh schreef op 24-10-2005 @ 17:25 :
Een CSV is ge-exporteerd op volgorde van kolommen zoals die in de de originele access db zaten. Je zou in je mysql database dan exact dezelfde kolomvolgorde aan moeten houden. Dat kan wenselijk zijn, maar ook niet. Bovendien kunnen datatypen niet overeenkomen, maar volgens mij neemt mysql dit sowiesow niet zo nauw hiermee.

Ik neem aan van wel dat de database hetzelfde blijft..
Anders moet de TS gewoon even een convertor bouwen...

Ninh schreef op 24-10-2005 @ 17:25 :
Een CSV is ge-exporteerd op volgorde van kolommen zoals die in de de originele access db zaten. Je zou in je mysql database dan exact dezelfde kolomvolgorde aan moeten houden. Dat kan wenselijk zijn, maar ook niet.

Wat boeit kolomvolgorde nauw nou? Dat is toch compleet niet interessant voor je database design?

eddie schreef op 24-10-2005 @ 17:34 :
Wat boeit kolomvolgorde nauw? Dat is toch compleet niet interessant voor je database design?

Voor de werking niet, maar als je enige vorm van conventie aan wil houden wel. Persoonlijk heb ik eerst al m'n primary en foreignkey fields, gevolgd door de rest.

Ninh schreef op 24-10-2005 @ 17:40 :
Voor de werking niet, maar als je enige vorm van conventie aan wil houden wel. Persoonlijk heb ik eerst al m'n primary en foreignkey fields, gevolgd door de rest.

Zozo, heb jij meerdere primary key fields in je tabel?

Verder is het inderdaad een kwestie van voorkeur. Voor het toevoegen van een nieuwe foreign key wordt het wel ingewikkelder om dezelfde volgorde aan te houden; je moet namelijk de bestaande tabel droppen en opnieuw aanmaken. Daarvoor moet je eerst je gegevens bewaren die je achteraf weer moet importeren.

eddie schreef op 24-10-2005 @ 17:44 :
Zozo, heb jij meerdere primary key fields in je tabel?

Nee, ik zie nu dat je het zo wel kon interpreteren ja

Verder is het inderdaad een kwestie van voorkeur. Voor het toevoegen van een nieuwe foreign key wordt het wel ingewikkelder om dezelfde volgorde aan te houden; je moet namelijk de bestaande tabel droppen en opnieuw aanmaken. Daarvoor moet je eerst je gegevens bewaren die je achteraf weer moet importeren.

Yep, moet je je trouwens eens voorstellen hoe normaliseren zou gaan als je al je keys zonder enige vorm van regelmaat in een tabel hebt .

Ninh schreef op 24-10-2005 @ 18:44 :
Yep, moet je je trouwens eens voorstellen hoe normaliseren zou gaan als je al je keys zonder enige vorm van regelmaat in een tabel hebt .

Als het goed is, is je database al in optimale vorm

eddie schreef op 24-10-2005 @ 18:58 :
Als het goed is, is je database al in optimale vorm

Dat is iets dat je iig nastreeft