WiX already uses OLE DB but it's used in a way specific to SQL Server. OLE
DB promised orthogonal access to different databases but it didn't really
work out like that - there are too many provider-specific options and so
much that isn't standardised. In practice you have to write different code
for different database providers to do anything that isn't in the very small
subset of shared SQL syntax (mainly limited to SELECT and DML syntax).
As an example, to detect whether a database already exists, WiX uses "SELECT
name FROM sysdatabases WHERE name='%s'". In SQL Server 2005 that's a
compatibility view and was replaced by the sys.databases catalog view.
There's a possibility it'll be removed in SQL Server 2008.
The SQL Server tasks are a mix of a compiler extension, C# code which
generates additional tables in the output, immediate custom actions written
in C++ which read those tables, and deferred and rollback custom actions
also written in C++ which are scheduled by the immediate custom actions to
actually do the work.
If you obtain the source, the WixSqlExtension (compiler extension and
provides a library containing the error and custom action definitions) lives
in src\ext\SqlExtension. The compiler and decompiler extensions live in the
wixext folder while the WiX source lives in the wixlib folder.
The custom actions haven't yet been refactored from WiX 2.0 and still live
in src\ca\serverca. The immediate actions live in the scasched folder, while
the deferred actions live in scaexec. These are compiled into scasched.dll
and scaexec.dll respectively - Windows Installer 1.0 does not permit an
immediate CA to schedule deferred actions that live in the same DLL. Both
make heavy use of the utility code in src\dutil\sqlutil.cpp and
src\ca\wcautil.
Any custom actions you might write are unlikely to be accepted into the WiX
source unless they follow this pattern: compiler extensions generating
custom tables, parsed by immediate custom actions which write the actual
tasks to perform into custom action data for deferred custom actions which
actually do the work.
--
Mike Dimmick
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Friedrich
Brunzema
Sent: 20 July 2007 22:12
To: Bob Arnson
Cc: WixUsers
Subject: Re: [WiX-users] Initializing a MySQL 5 database
Bob,
thanks for the information regarding SQL support in Wix. Could one not use
OleDB or one of the other database access technologies (ODBC) that use a
connection string to get all databases covered in one go? I can take a look
at the source to see how hard it would be to add MySQL support to Wix
(presumably in C++?) with the MySql client library, but I promise nothing.
Is there a good example of a creating a fragment somewhere?
thanks,
Friedrich
----- Original Message ----
From: Bob Arnson <[EMAIL PROTECTED]>
To: Friedrich Brunzema <[EMAIL PROTECTED]>
Cc: WixUsers <wix-users@lists.sourceforge.net>
Sent: Friday, July 20, 2007 12:53:25 PM
Subject: Re: [WiX-users] Initializing a MySQL 5 database
Friedrich Brunzema wrote:
I noticed that there is some SQL support in Wix, but did not find extensive
documentation on this (or an example). At first glance my guess is that
this only works for SQL server installations. Does someone have more
information?
Yes, it's SQL Server-specific. We've talked about adding support for non-MS
databases, especially since both PostgreSQL and MySQL feature installers
built with WiX.<g> But so far, nobody's volunteered.
The setup is actually installing the entire MySQL database (after
reverse-engineering the MySQL setup), which also works great, but now causes
4-5 min build times for light to compress all the files. I have actually
separated the mysql portions into a merge module , which basically works and
reduces the build to < 1 min, but now the custom actions break, since the id
that [#mysql.exe] references is in another file - I get a missing foreign
key error message from one of the ICE checkers.
Unless you need to share the merge module, the easiest solution is to create
a Fragment instead of a Module. Use Lit to create a .wixlib that contains
all the files. Otherwise, you need to include all the related files in the
same module.
--
sig://boB
http://joyofsetup.com/
_____
Ask a question on any topic and get answers from real people.
<http://ca.answers.yahoo.com> Go to Yahoo! Answers.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
