MDB editor

[Camel]

[semi-OT]
anybody know any .mdb editors? i'm switching my bot over to an odbc powered database, but not everybody has MS Access. i already plan to add an internal editor, but i'm looking for a temporary quick-fix until it's stable.
[/semi-OT]

[c0ol]

uhh odbc, access!?!?!

* c0ol pushes the toy box aside.  use like 'mysql'

[Camel]

there are mysql drivers for odb
the whole point of using odbc in the first place was so that it could be switched over to an sql server with zero modification to the exe

[Grok]

Camel, use ADOX instead of ODBC direct.  With ADOX you can create your own access database in your code, then use ADO to access the data (with ODBC as the access method, but OLE DB is preferred over ODBC).

Later, ADOX can be used to create the database in SQL Server if it does not exist.  Thus your bot will not have to be rewritten for two different platforms.  You will have to write separate code to create the access database vs create the SQL Server database.

HTH,
Grok

[Camel]

i already am using ADO
if you've been following my posts, one of the biggest goals of my bot is to ship with no dll/ocx files (aside from the vb runtimes...although it wont "ship" with those anyways). on top of that, it would be insane to assume that everybody's computer has DSNs set up exactly like mine--i'm only using the drivers:

Code Select Expand

   Database.ConnectionString = "DBQ=" & App.Path & "\bnubot.mdb;" & _
                               "DefaultDir=" & App.Path & ";" & _
                               "Driver={Microsoft Access Driver (*.mdb)};" & _
                               "DriverId=25;" & _
                               "FIL=MS Access;"

[edit] oh and grok, i most certainly would not need different code to create the databases even if i did. the differences in the sql syntax between access and mysql/pgsql is beyond minimal. if done right, there should be zero bumps going from one to the other (eg, using "SELECT TOP x..." instead of "SELECT...LIMIT x"--even though limit makes more sense). furthermore, i have never been able to get an ms access table to NOT work with mysql (going the other way has obvious flaws, as access sucks). the only concern one would have -- could have -- would be about security to the table, and that has nothing to do with how the bot works (aside from allowing the user to, say, input a username and password to log in to the database)

feel free to refute anything i've said

[Skywing]

i already am using ADO
if you've been following my posts, one of the biggest goals of my bot is to ship with no dll/ocx files (aside from the vb runtimes...although it wont "ship" with those anyways). on top of that, it would be insane to assume that everybody's computer has DSNs set up exactly like mine--i'm only using the drivers:

Code Select Expand

   Database.ConnectionString = "DBQ=" & App.Path & "\bnubot.mdb;" & _
                               "DefaultDir=" & App.Path & ";" & _
                               "Driver={Microsoft Access Driver (*.mdb)};" & _
                               "DriverId=25;" & _
                               "FIL=MS Access;"

[edit] oh and grok, i most certainly would not need different code to create the databases even if i did. the differences in the sql syntax between access and mysql/pgsql is beyond minimal. if done right, there should be zero bumps going from one to the other (eg, using "SELECT TOP x..." instead of "SELECT...LIMIT x"--even though limit makes more sense). furthermore, i have never been able to get an ms access table to NOT work with mysql (going the other way has obvious flaws, as access sucks). the only concern one would have -- could have -- would be about security to the table, and that has nothing to do with how the bot works (aside from allowing the user to, say, input a username and password to log in to the database)

feel free to refute anything i've said

ADO != ADOX.

[Banana fanna fo fanna]

Could have it talk to a mysql server!

[Camel]

ADO != ADOX.

uh..what?  

[Grok]

ADO != ADOX.

uh..what?  

lmao.  skywing felt free to refute the first thing you said.  correctly, too.

ADOX is a different library than ADO.  While ADO is concerned with the objectifying your data sets and querying methods, ADOX is geared towards the schema and structures, discovery and creation, of the databases.  I think, but not sure, they use DDL or DML to communicate with the db drivers, but that's only a guess and not really important.

If you're using ADO, you have zero chance of distributing your bot without DLLs and expecting it to work.  That is unless your "target platform" is designated as "a Windows PC that already has MDAC ver x.x on it".

On the subject of DSNs, you may wish to research the ODBC and ODBC.INI keys in the Windows registry.  They contain the specifics of each DSN.  You can build your own DSNs by creating registry entries, thus not requiring anything but Registry API.  Note, however, that you still must supply the appropriate database driver if not already on their system.

Hmm, very likely your only way to distribute a nondependent, non DLL'd program that does databases is to write your own database implementation right into the bot.  Or, require that everyone have one of [x,x,x,x,x] installed already, and you just detect the supported systems and display their installed options as choices.