Connecting to an SQL Database.
-
Bram van Kampen wrote:
How do I access that with SQL,
You create a connection and execute commands. You'd need to change your connectionstring, and probably use the
OleDbConnectionBram van Kampen wrote:
and do the SQL Constructs make sense for a pure SQL database.
It uses SQL, but I don't know how the word "pure" fits in.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
Bram van Kampen wrote:
and do the SQL Constructs make sense for a pure SQL database.
It uses SQL, but I don't know how the word "pure" fits in.
Well, 'Pure' fits in as follows:- SQL stands(as you know) for 'Standard Queery Language', and was as such originally designed and intended to formulate queeries to a Database in a uniform way, for mutualy incompatible Databases in say DBase, Access, etc. I.E. it was an abstraction layer to create a common access method to Databases in various proprietary binary formats . MS SQL implements this abstraction layer, but can also be used to act as DB propper. That is: one can create a DB complete with tables and colums from scratch in SQL, without also specifying seperately an underlying Database (This is a step further than intended in the 1980's). This later concept is what I describe, (for want of a better word) as a'pure' SQL database. 'Pure' in the sense that to the user only SQL is involved, and no other underlying database. I understand from your answer that the connection string would be different. I extrapolate from the above that, provided Tables and Colums are identical in type and name, that the transaction and queery strings should not need changing when stepping back from Access to 'Pure' SQL. :)
Bram van Kampen
-
Eddy Vluggen wrote:
Bram van Kampen wrote:
and do the SQL Constructs make sense for a pure SQL database.
It uses SQL, but I don't know how the word "pure" fits in.
Well, 'Pure' fits in as follows:- SQL stands(as you know) for 'Standard Queery Language', and was as such originally designed and intended to formulate queeries to a Database in a uniform way, for mutualy incompatible Databases in say DBase, Access, etc. I.E. it was an abstraction layer to create a common access method to Databases in various proprietary binary formats . MS SQL implements this abstraction layer, but can also be used to act as DB propper. That is: one can create a DB complete with tables and colums from scratch in SQL, without also specifying seperately an underlying Database (This is a step further than intended in the 1980's). This later concept is what I describe, (for want of a better word) as a'pure' SQL database. 'Pure' in the sense that to the user only SQL is involved, and no other underlying database. I understand from your answer that the connection string would be different. I extrapolate from the above that, provided Tables and Colums are identical in type and name, that the transaction and queery strings should not need changing when stepping back from Access to 'Pure' SQL. :)
Bram van Kampen
Bram van Kampen wrote:
I extrapolate from the above that
Wrong assumption. Although you can force both to use SQL92, it's not optimal. Both have their own SQL-dialect, and there's a little difference in adding parameters to the IDbCommand. Still, I like Access for prototyping Sql-server database; one can build a UI quickly around the tables, and they're easily copied to a USB-stick. There's a Wizard somewhere in there that "upgrades" the database to Sql Server-format, so once it works you can migrate all the tables easy from Access. The wizard can't translate all, e.g., there's no UI-service in Sql Server. It also doesn't translate reports, but tables and views, yes. If you want to be able to use the Access-reports with the Sql Server database, that's possible too - by linking the tables from Access and installing the free Access Runtime[^].
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]