2011-08-22 2 views
0

J'ai un problème avec la création d'une requête dans Access. Je voudrais avoir une requête, qui après l'exécution demandera sur le nom et le prénom du nouvel enregistrement dans la table acheteurs, puis créer une nouvelle table pour cet acheteur (par exemple pour John Smith - appelé SmiJoh - 3 lettres de nom et 3 Prénom).Créer une table - nom dynamique de la table

Des idées comment faire cela sans VBA, en utilisant seulement SQL?

PS. S'il n'y a aucune chance de faire tout cela en utilisant SQL, est-il possible de faire seulement une requête en créant une table avec ce nom?

+4

C'est une mauvaise idée de créer des tableaux personnalisés à la volée. Pourquoi avez-vous besoin d'une table par acheteur? – Jacob

+0

Mon erreur dans l'écriture - table s'appellera Acheteur. Donc, mon idée est que chaque utilisateur de la base de données n'a accès qu'à sa table, et là il ajoute les clients avec lesquels il fait une affaire, le coût de la transaction, etc. Et il y aura un administrateur, qui a accès à MainTable dans lequel il y aura tous les records pour tous les acheteurs. – Amber

+2

Le même principe s'applique toujours. Placez les accords dans une table de transactions, les clients dans une table de clients, les acheteurs dans une table d'acheteurs et associez-les aux clés primaires/clés étrangères. – Jacob

Répondre

0

Avez-vous essayé d'utiliser un EXEC

DECLARE @Name VARCHAR(6) 
SET @Name = 'SMIJOH' --Query your table name 
EXEC ('CREATE TABLE ' + @Name + ' (ID INT IDENTITY(1,1), etc....)') 
+2

MS Access ne semble pas avoir de déclaration l'exécution de requêtes dynamiques, d'après ce que j'entends. Qu'est-ce que vous avez posté est le plus susceptible de choses SQL Server et il ne fonctionnera pas dans MS Access. –

1

vous a demandé si vous pouvez faire quelque chose comme ceci avec SQL dans Access, où nom_table est une valeur que vous fournissez lorsque l'instruction est exécutée.

CREATE TABLE [table_name](
    id COUNTER CONSTRAINT pkey PRIMARY KEY, 
    date_field DATETIME); 

Non, le moteur de base de données Access ne vous permettra pas d'utiliser un paramètre pour le nom de la table.

Mais comme les commentaires que vous avez reçus, je vous encourage à reconsidérer votre plan pour créer un tableau séparé pour chaque acheteur. Ce sera un gâchis compliqué à construire et à maintenir.

Utilisez une seule table pour stocker les données de tous les acheteurs. Inclure un champ pour identifier l'acheteur. Utilisez ensuite une requête qui récupère uniquement les lignes où le champ buyer_id correspond à buyer_id de l'utilisateur actuel. Construire un formulaire avec cette requête comme source d'enregistrement. Voici un exemple de tableau où le champ uname contient le nom du compte Windows.

id uname time_only 
5018 fred 7:00:00 AM 
5063 hans 2:00:00 AM 
5072 hans 3:00:00 AM 

Avec la fonction fOSUserName() Dev Ashish (Get Login name), cette requête renvoie uniquement les lignes où uname correspond à mon nom d'utilisateur Windows (hans).

SELECT d.id, d.uname, d.time_only 
FROM discardme AS d 
WHERE d.uname = fOSUserName(); 

J'ai créé un formulaire basé sur cette requête qui comprend une zone de texte lié à uname avec ces propriétés dans l'onglet Données de la feuille de propriétés: Valeur par défaut = fOSUserName(); Activé Non. Si vous ne voulez pas que l'utilisateur voie même la valeur uname, définissez Visible No dans l'onglet Format.

Vous devez toujours verrouiller l'application pour empêcher les utilisateurs d'ouvrir la table directement. Mais cela serait également nécessaire avec votre schéma d'origine pour créer une table distincte pour chaque acheteur.

Une approche similaire pourrait fonctionner si vous avez configuré ULS (sécurité au niveau de l'utilisateur), ce qui nécessite un format MDB db; il n'est pas pris en charge dans le nouveau format db de l'ACCDB. Dans ce cas, la fonction VBA CurrentUser() renverra le nom du nom d'utilisateur de sécurité Access. Modifier la requête en conséquence:

SELECT d.id, d.uname, d.time_only 
FROM discardme AS d 
WHERE d.uname = CurrentUser(); 

Notez que sans ULS, CurrentUser() vous donnera le nom du compte utilisateur par défaut, Admin.

Enfin, tenez compte de vos exigences de sécurité. Faire cela avec Access 'Jet/ACE pour le stockage de données reviendra à offrir des conseils aux utilisateurs coopératifs. Cependant, que vous adoptiez ou non l'ULS, vous ne pouvez absolument pas empêcher un utilisateur de voir l'une des données.Si vos exigences de sécurité sont plus strictes, déplacez le stockage de données vers une base de données client-serveur (SQL Server, par exemple). Vous pouvez toujours utiliser votre application Access en tant que frontal en substituant des liens ODBC aux tables du serveur pour les tables Jet/ACE natives existantes.

Questions connexes