Is it possible to establish ADBC if ODBC is not installed ?
At least as of Acrobat 9, ADBC requires ODBC.
The Acrobat extensions to JavaScript provides an ODBC-compliant object model called Acrobat Database Connectivity (ADBC), which can be used in document-level scripts to connect to a database for the purposes of inserting new information, updating existing information, and deleting database entries. ADBC provides a simplified interface to ODBC, which it uses to establish a connection to a database and access its data, and supports the usage of SQL statements for data access, update, deletion, and retrieval.
Thus, a necessary requirement to the usage of ADBC is that ODBC must be installed on a client machine running a Microsoft Windows operating system. In addition, ADBC does not provide security measures with respect to database access; it is assumed that the database administrator will establish and maintain the security of all data.
(emphasis added)
Related
I want to define all the acces rights in my SQL Server database so it is nice and centralized. I am implementing basic stuff like grant select on schemas and tables, encryption of columns and RLS.
On top of the database I build a Tabular model with SSAS with DirectQuery connection.
On top of the Tabular model I want to build a report with DirectQuery connection.
directQuery states:
Security can be enforced by the back-end source database by using row-level security features from the database.
Impersonation in Analysis Service Tabular states:
Impersonate Current User Specifies data should be accessed from the datasource using the identity of the user who sent the request. This setting applies only to DirectQuery mode.
Issue:
I cannot choose "use current user" as impersonation mode in my ssas tabular model. -> "ssas the datasource contains an impersonationmode that is not supported for processing operations"
changing the impersonation mode in ssms yields this error, VS2019 looks similar with the same content
I can deploy it as a specific user but that means that everybody uses the access rights of that specified user.
My tabular model uses compatibility level 1400. It is deployed to a Microsoft Analysis Server 15.0.32.50, Tabular Mode. (The model cannot use DirectQuery when in compatibility 1500 for some arcane reason. Please don't make this your topic unless you absolutely have to.)
SQL Server Version is 2019, 15.0.2000.5
The on-premise Report Server must be used.
SSAS, database and report server run on the same SQL Server.
Is it possible to implement this solution using database, ssas and report server on the same machine? If so, how?
Alrighty, so after messing around with this stuff for wayyy too long, I narrowed it down to the SQL-Server setup. Something there in the configuration is causing a bunch of issues.
Using direct query to pass down user information in the way described above is perfectly valid.
I am working on a desktop application using VB.net which stores data on an sqlite database. The client says that they want the app to be accessed over the LAN by different departments. Is it possible that SQLIte can work in this setup?
No. SQLite isn't meant to be used by multiple clients at the same time (unless it is strictly read-only).
You should use a server style database (SQL Server, PostgreSQL, MySQL, etc.).
If you really want a file-based database, Access is the only one I know of that will work over a LAN with multiple users.
Yes. SQLite can access database files on a network file system, and does handle concurrent accesses correctly (if the OS and the network implement locking correctly (many don't; see How To Corrupt An SQLite Database File)).
However, SQLite is a file-based database system; like Access, it is not really designed for network operation (see Appropriate Uses For SQLite).
Consider using a client/server database, if possible.
I'm looking for a SQL database engine that I can distribute with a C# Winforms application. The requirements are:
Will store about 1GB of text (measured before any compression).
Database must be encrypted, the encryption key will be supplied by the application at runtime.
Compression (prior to encryption) would be nice, so that corrupt databases can be replaced remotely over a low-bandwidth network
connection.
Reliability, replacing a corrupt database can involve an expensive site visit.
Low licencing costs and support costs.
Users will only access the data via the application, so no fancy UI required.
Options I've considered:
Sybase SQL Anywhere - OK, but not "free".
MS SQL Server Express - no whole-database encryption!
SQLite - encryption requires a licence payment?
VistaDB - not "free".
What other products fit the bill?
Get the Visual Studio "SQLite/SQL Server Compact Toolbox" Extension. Using this:
Microsoft.SqlServer.Compact from Nuget will create encrypted databases provided you manually run the command
Create Database "something.sdf" databasepassword 'somepassword'
in the extension's query window.
System.Data.SQLite.Core from Nuget will use encrypted databases provided you use the above extension to create the database and key in a password at database create time.
My database must be updated at arbitrary intervals, manually, with new info to put on standart tables that don't require structural modifications. one app will update the database.
Another app, the one I will distribute (to friends and family only, but doesn't require any security feature to it, like encrypting the database) will read the database and use its data on labels, listviews, etc.
The problem is, I'm the perfect definition of full-fledged n00b at programming of any sort, and still don't know what database to use.
I thought that I should use a SQL CE (*.sdf) file, and store that database thing on an FTP. then, I could download it and get data from it everytime the "client" app runs, and certain button ("connect") is clicked.
After some hard-core googling, I found out how to connect to the sdf thing, using this connection string:
Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=D:\Documents and Settings\Camilo\JCTM.sdf
So it connects, or at least didn't show any error.
I don't know if it's a good idea to use sdf SQL CE files as databases, if it's too hard maybe I should go for XML? what do you guys suggest, what is the easiest way to implement very simple databases in VB.NET?
By simple databases I mean:
- no search needed
- no advanced features except storing strings on tables with columns and rows
- easy to access, read, edit, etc. by different VB.NET apps
Is sdf a good idea?
I would recommend Sql Server Express Its free and can be redistributed with .net applications as part of the install process.
The challenge will be syncing the changes between the different clients. If you have access to a FTP server, you may have the ability to host a website in IIS. If you can do that you can just use webservices and read against one database instead of copying one local.
Luckily for you, you can abstract away the need to be concerned with which back-end database you use to store your data.
Technologies such as ODBC (Open Database Connectivity) and OLEDB (Object Linking and Embedding, Database) allow you to limit your concern for the backend datastore to the task of crafting your connection string. In your example, the connection string says, "I'm going to connect to a SQL Server CE database via its OLEDB provider, and it's physically located over on D:/...
Within the code, you use standard OLEDB mechanisms to access and manage the database. Because of this abstraction, you can use OLEDB providers for SQL Server, Oracle, XML, Access or comma delimited text files as your backing store if you wish, and the only change you need to make to your code is the connection string. Your choice then should be to pick the database that you have the tools and know-how to set up and manage initially.
I'd start with Microsoft Access because it has its own UI, and can play well with .NET.
You can also try the ADO.Net implementation for SQLite, which I've also found very useful.
I've written a small (8-10 laptops) point-of-sale system running over a wireless network, as an HTA that reads from/writes to an Access MDB located on a network share.
I need to use ADO - GetString and the user roster are not available with DAO.
I also need to use DAO - the MDB cannot be compacted with ADO.
I know that:
1) If the database backend is not an Access MDB, I should use ADO.
2) If the backend is an MDB, but I want to upgrade to SQL Server at some point, I should use ADO.
3) Within an Access application, or any other VBA/VB application, I should use DAO, as ADO must go through a translation layer of the Jet OLE DB Provider, while DAO is more direct.
4) VBScript/JScript allows me to use either DAO or ADO.
The two-part question is as follows:
1) In this software environment (HTA/scripting), is it better to use ADO rather than DAO?
2) Does ADO offer any benefits because the HTA is reading/writing over a wireless network?
If the only reason you need DAO is to compact the database, you can use DAO for that, and use ADO for everything else. You are not limited to using only ADO or DAO.
The biggest benefit of using ADO is that it will be easier to move to SQL Server Express when the time comes. You should do that sooner rather than later, as SQL Server Express offers all of the benefits of MSAccess databases without the drawbacks. SQL Server Express is free, and it will easily handle the system size you are proposing.
Access databases corrupt easily in a multi-user environment, especially when a wireless network is involved. If you are worried about losing the benefits of working in MSAccess, you can still attach to SQL Server using linked tables, and work with your SQL Server Express database that way.
You can also use JRO to compact your MDB file. This will be included with any recent version of MDAC, installed by default on XP and later systems. No installation of Access is necessary.
To answer your specific questions:
1) I would opt for ADO just because it is more current, and the same API can be used in other kinds of scripting, like LDAP/ActiveDirectory access, reading file system folders, reading MAPI mail, and working with other types of semi-structured text files like fixed width text and CSV. It's not specifically better for the HTA programming environment, but its perhaps better for you to learn a more widely applicable API. I also thinks it's an easier API to work with, but I started with it and only later worked on some older DAO projects.
2) One possible benefit that ADO provides is that of disconnected recordsets, which may have an advantage or at least suggest some architectural alternatives in your wireless network setup. You open a recordset, then disconnect it, so you can still work with the data in memory, but not have to leave a database connection open. Then at a later time you can reconnect and update the database. Also, you can work in a fully disconnected style by managing tables as local XML or ADTG files.
You might shoehorn DAO into working from VBScript but that's an odd pairing. ADO makes the most sense in general.
Another advantage of ADO would be that it supports RDS over DCOM or HTTP. This can be used to overcome many of the limitations of Jet MDBs used via file sharing, such as the corruption unreliable networks and clients can lead to. It also cuts the amount of traffic over the network, improving performance. In addition it offers a middle tier in which business objects can "live" and all of this can be mediated using COM+ where applicable.
Of course you no longer have the option of using a simple P2P network and a file share to host the database. RDS needs a server to host the process and run the Jet engine, which no longer needs to run on each client system. This means you can use Jet stored procedures that run on the server, offloading more client processing and network traffic. While not as sophisticated as T-SQL or other alternatives, this ADO/Jet 4.0 OLE DB Provider exclusive technology offers tangible benefits that can't be had using DAO.
RDS can mask much of the process of using disconnected Recordsets, simplifying client code. It uses ADTG under the hood, which was developed and optimized for this very purpose.
However using RDS requires more infrastructure and expertise than a simple file share. You might as well look into a low-end version of SQL Server.
In general I'd recommend using the jetcomp.exe utility to compact and repair, over either DAO or JRO. It offers a number of advantages.
If you can afford to use a HTA application with Access instead of a more performant platform, I would say you should go with the easiest api for you. The bottleneck will never be the abstraction of db access in your case. Still, DAO is really old.